Simon Marchi [Thu, 15 Jan 2026 03:55:26 +0000 (22:55 -0500)]
gdb/dwarf: remove support for DWP v1
The GCC wiki [1] says that version 1 of the DWP format "was an
experimental version that is no longer supported". That comment was
written in 2013. From what I understand, DWP version 1 was not widely
adopted. Unlike version 2 and version 5 (which is part of DWARF 5).
I propose to get rid of v1 support, which allows removing a bit of code,
making things a bit easier when reasoning about DWARF code.
[1] https://gcc.gnu.org/wiki/DebugFissionDWP
Change-Id: Ie46b55662e63b7f341b7827330154ec4ab5af9e5 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 15 Jan 2026 03:55:25 +0000 (22:55 -0500)]
gdb/dwarf: initialize fields of virtual_v2_or_v5_dwo_sections
I noticed that create_dwo_unit_in_dwp_v2 and create_dwo_unit_in_dwp_v5
initialized structure virtual_v2_or_v5_dwo_sections differently, one
with a memset and one with default initialization. Make that consistent
by moving the initialization in the struct itself, which is less
error-prone anyway.
Change-Id: I48a21a871601d076bbeeb19befd0ad62e9ba7f2a Approved-By: Tom Tromey <tom@tromey.com>
Kito Cheng [Mon, 12 Jan 2026 08:26:32 +0000 (16:26 +0800)]
RISC-V: Add second-pass relaxation for JAL to C.J/C.JAL
When linker relaxation converts CALL (auipc+jalr, 8 bytes) to JAL
(4 bytes), further relaxation to C.J or C.JAL (2 bytes) may become
possible as code shrinks and jump distances decrease.
This patch adds _bfd_riscv_relax_jal to perform this second-pass
relaxation. To enable this, we introduce R_RISCV_DELETE_AND_RELAX,
a new internal relocation that combines piecewise deletion with
preservation of relaxation capability. When _bfd_riscv_relax_call
relaxes CALL to JAL, it marks the deletion as R_RISCV_DELETE_AND_RELAX
instead of R_RISCV_DELETE. After the piecewise deletion is resolved,
R_RISCV_DELETE_AND_RELAX is converted back to R_RISCV_RELAX at the
JAL instruction offset, allowing _bfd_riscv_relax_jal to further
relax JAL to C.J/C.JAL.
C.JAL is only available on RV32 (rd=ra), while C.J is available on
both RV32 and RV64 (rd=x0).
Changes since v1:
- Use R_RISCV_DELETE_AND_RELAX with piecewise deletion instead of
calling _riscv_relax_delete_immediate directly, to maintain
relaxation performance.
- Add preserve_relax parameter to riscv_relax_delete_bytes to
simplify the logic in _bfd_riscv_relax_call.
MIPS/BFD: Initialize `error_message' in `_bfd_mips_elf_orphan_shr16_reloc'
There is no value assigned in `_bfd_mips_elf_generic_reloc' via the
`error_message' parameter and consequently the original `error_message'
variable in `_bfd_mips_elf_orphan_shr16_reloc' remains uninitialized in
the error case, which newer versions of GCC can correctly diagnose:
In function '_bfd_mips_elf_orphan_shr16_reloc',
inlined from 'mips_elf_free_hi16_list' at ../../binutils-gdb/bfd/elfxx-mips.c:13309:12:
../../binutils-gdb/bfd/elfxx-mips.c:13281:5: error: 'error_message' may be used uninitialized [-Werror=maybe-uninitialized]
13281 | _bfd_link_reloc_status_error (abfd, info, hi->input_section,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
13282 | &hi->rel, error_message, r);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../binutils-gdb/bfd/elfxx-mips.c: In function 'mips_elf_free_hi16_list':
../../binutils-gdb/bfd/elfxx-mips.c:13255:9: note: 'error_message' declared here
13255 | char *error_message;
| ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
Fix the problem by preinitializing the variable to NULL as at other
places.
Alan Modra [Wed, 14 Jan 2026 22:28:44 +0000 (22:28 +0000)]
Move mips_hi16_list to mips_elf_section_data
This patch is in response to fuzzing testcases that manage to cause
segfaults due to stale references to freed memory via mips_hi16.data.
A number of the error/warning handlers in ldmain.c use %C. This can
cause debug info to be parsed for the first time in order to print
file/function/line. If one of those warnings is triggered after some
hi16 relocs have been processed but before the matching lo16 reloc is
handled, *and* the debug info is corrupted with a lo16 reloc, then the
mips_hi16_list will be flushed with the result that printing a warning
changes linker output. It is also possible that corrupted debug info
adds to the hi16 list, with the result that when the linker handles a
later lo16 reloc in a text section, ld will segfault accessing
mips_hi16.data after the debug buffers have be freed. Both of these
problems are fixed by keeping a per-section mips_hi16_list rather than
a per-file list.
MIPS: Add tests for orphan REL HI16 relocation addend processing
Add GAS and LD test cases for orphan REL HI16 relocation processing,
including verification of the addends produced as well as the warning
messages expected.
Due to the ordering used for the list of oustanding cached HI16 reloc
entries warnings for non-ELF links are issued in the reverse order
compared to one for ELF links. This is not considered a defect as all
the required warnings are produced in both cases, however separate
warning lists are required and included here for ELF and srec output.
Correct the addend being ignored for orphan REL HI16 relocations.
For assembly and non-ELF links `_bfd_mips_elf_hi16_reloc' is called from
`bfd_install_relocation' and `bfd_perform_relocation' respectively via
the respective howtos. It caches the relocation for later processing as
`_bfd_mips_elf_lo16_reloc' is called via the corresponding LO16 reloc's
howto, at which point both the HI16 and the LO16 parts are calculated
and installed.
If no matching LO16 relocation has been later encountered, then the
cached entry is never processed, with the outstanding cached entries
silently dropped at the conclusion of processing, resulting in zero
addend being used for the field relocated.
Dropping of the entries only happens in `_bfd_mips_elf_free_cached_info'
at the time the BFD is being successfully closed and section contents
long written to output. For non-ELF links dropping will also execute in
`_bfd_elf_mips_get_relocated_section_contents' via a separate piece of
code if the function has encountered an error.
Address the issues first by factoring out code to process outstanding
cached entries to `mips_elf_free_hi16_list' and then by making the
function actually install the relocations cached as required. This has
to happen before section contents have been written and therefore the
success path wires the function call to `bfd_finalize_section_relocs',
for assembly and `_bfd_elf_mips_get_relocated_section_contents' for
non-ELF links.
For housekeeping purposes the latter call will just drop cached entries
as it happens now in the case of an error, and likewise the call from
`_bfd_mips_elf_free_cached_info' is retained in case a fatal error in
the assembler prevents `bfd_finalize_section_relocs' from being called.
This also results in a warning being issued now about orphan REL HI16
relocations encountered in non-ELF links. Previously no such warning
was produced since the cached entries were dropped. For assembly we
expect the tool to have issued its own warning, so we process orphan
relocations silently if successful, but still issue a warning if an
error is returned.
We are careful in `mips_elf_free_hi16_list' to retain any incoming BFD
error as the function may be called under an error condition and if
there's another failure in processing at this stage we don't want to
clobber the original error.
MIPS/BFD: Fix ELF link orphan REL HI16 relocation addend processing
Correct the addend being ignored for orphan REL HI16 relocations.
For ELF links `_bfd_mips_elf_relocate_section' handles relocation and
uses `mips_elf_add_lo16_rel_addend' to shift the incoming HI16 in-place
addend into its intended [31:16] bit positions and combine it with the
LO16 part. If no matching LO16 reloc has been found, then the function
returns early and consequently the incoming HI16 addend is not shifted
and remains in bits [0:15]. For final links any value of the symbol
referred is then added. Then the final value is shifted back into bits
[0:15] for installation into the field relocated. It is obviously wrong
as the original HI16 in-place addend has now been lost.
Fix the issue by shifting the incoming HI16 in-place addend before using
`mips_elf_next_relocation' to find the matching LO16 relocation. Then
upon early return from `mips_elf_add_lo16_rel_addend' the addend is in
the intended [31:16] bit positions already.
Use the warning callback for the orphan REL HI16 relocation warning just
as with any other linker relocation processing warnings, standardizing
the message format and providing source location where available.
MIPS/GAS: Warn about unmatched REL HI16 relocations
Ever since commit 749b8d9d455c ("PATCH: ld/4208: `final link failed: Bad
value' when building Linux MIPS kernels."), which went in back in 2007,
<https://inbox.sourceware.org/binutils/20070320043504.GA7735@lucon.org/>,
we've been warning about unmatched HI16 REL relocations in the linker,
as it has been concluded in the discussion on PR ld/4208 that we have no
need to be forgiving about compiler bugs that lead to object files to be
made that are not compliant with the psABI.
However no corresponding update has ever been made to GAS, despite that
it's always helpful to issue a warning as early as possible in the build
process. In this particular case GAS also has more information to hand
as it always has the full original addend available that has been used
for both the high-part and the low-part relocation, while the linker has
to rely on the in-place value stored in the relocatable field by earlier
processing, which has necessarily been truncated. Therefore the linker
may miss cases where unrelated high-part and low-part relocations have
been put next to each other that had significantly different addends at
assembly time (small differences are deliberately permitted where they
are known not to affect any borrow from the high part).
Additionally GAS is able to point at the exact place in sources where
any offending orphan relocations have been used.
Update GAS to issue the warning then where applicable and remove an old
comment referring to GCC producing orphan HI16 relocations.
BFD: Make `bfd_finalize_section_relocs' return status
Update `bfd_finalize_section_relocs' to return status so that backends
can fail in this interface and propagate that to the respective callers.
Add suitable error reporting there. No failure cases in the existing
handlers though.
BFD: Rename `*_set_reloc' to `*_finalize_section_relocs'
The `*_set_reloc' interface is to be called at the conclusion of section
relocation processing, however its name reflects a particular action to
take rather than the context of invocation. Implementation is already
backend-specific.
Rename the interface such as not to make its name artificially limit the
intended purpose. Update the callers and documentation accordingly. No
functional change.
Fold a separate call to `bfd_set_reloc' into SET_SECTION_RELOCS itself,
so that the GAS interface to this facility is contained in a single
invocation.
Currently both `write_relocs' and `obj_mach_o_reorder_section_relocs'
call `bfd_set_reloc', causing the function to be called twice by Mach-O
targets, such as `i386-darwin', once before target-specific processing
and again afterwards, which is at the very least fragile in terms of
assuming that any actions made by the function on the first invocation
won't interfere with the final intended result.
Set the macro by default to a plain call to `bfd_set_reloc', letting
backends override the macro, with the requirement now to factor in a
call to said function at the appropriate time. Backends can choose
whether to call `bfd_set_reloc' first (such as COFF), or last (such as
Mach-O), or at any other point in relation to their own additional
actions.
Update the COFF variant accordingly, moving it to a new function for a
better code structure, retaining functionality.
This is in preparation for `bfd_set_reloc' to return an error status.
Tom de Vries [Wed, 14 Jan 2026 20:41:45 +0000 (21:41 +0100)]
[gdb/testsuite] Speed up gdb.base/tls-dlobj.exp
In test-case gdb.base/tls-dlobj.exp we use breakpoints to step through the
executable. The breakpoints are used only once, but they are permanent, so we
end up with 11 breakpoints, 10 of which of the form $srcfile:$n.
The executable loads and unloads shared libraries, triggering solib events in
gdb, which will re-set the breakpoints.
Setting a breakpoint of the form $srcfile:$n triggers a filename search that
iterates over all CUs in all objfiles for which we have debuginfo.
In case glibc debuginfo is installed, and in case we have a slow gdb, for
instance because of building with -O0 and Address Sanitizer, this might become
noticeable.
While it's a good idea to try to speed up this search (see for instance
PR33781), measuring this speed is not the point of this test-case, so fix this
by making the breakpoints temporary.
Jan Vrany [Wed, 14 Jan 2026 14:31:36 +0000 (14:31 +0000)]
gdb/jit: add function symbols to global block
While playing with JIT reader I realized that it is not possible to set
a breakpoint on jitted function:
(gdb) b jit_function_stack_mangle
Function "jit_function_stack_mangle" not defined.
Make breakpoint pending on future shared library load? (y or [n])
The problem is that symbols for jitted functions (jit_function_stack_mangle
in the above example) are not added to jitted compunit's global block:
(gdb) maint print symtabs
...
Symtab for file at 0x55d6f8c186c0
Read from object file << JIT compiled code at 0x5555555592a0 >> (0x55d6f8cd4090)
Language: unknown
Line table:
line 1 at 0x7ffff7fbc000 (stmt)
line 0 at 0x7ffff7fbc001 (stmt)
Blockvector:
block #000, object at 0x55d6f8c188b0, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc011
block #001, object at 0x55d6f8c18910 under 0x55d6f8c188b0, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc011
block #002, object at 0x55d6f8c18730 under 0x55d6f8c18910, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc00a, function jit_function_stack_mangle
block #003, object at 0x55d6f8c187f0 under 0x55d6f8c18910, 0 symbols in 0x7ffff7fbc00a..0x7ffff7fbc011, function jit_function_add
This commit changes JIT reader to add jitted functions to the global
block:
...
Blockvector:
block #000, object at 0x55ed6665b180, 2 symbols in 0x7ffff7fbc000..0x7ffff7fbc011
void jit_function_stack_mangle(); block object 0x55ed6665b000, 0x7ffff7fbc000..0x7ffff7fbc00a
void jit_function_add(); block object 0x55ed6665b0c0, 0x7ffff7fbc00a..0x7ffff7fbc011
block #001, object at 0x55ed6665b230 under 0x55ed6665b180, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc011
block #002, object at 0x55ed6665b000 under 0x55ed6665b230, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc00a, function jit_function_stack_mangle
block #003, object at 0x55ed6665b0c0 under 0x55ed6665b230, 0 symbols in 0x7ffff7fbc00a..0x7ffff7fbc011, function jit_function_add
Jens Remus [Wed, 14 Jan 2026 12:25:21 +0000 (13:25 +0100)]
gas: sframe: simplify get_offset_size_in_bytes
Type offsetT is either defined as signed 32-bit or 64-bit integer
depending on whether BFD64 is defined. Do not test for whether an
offsetT value exceeds INT32_MIN..INT32_MAX for !BFD64 32-bit offsetT
(or INT64_MIN..INT64_MAX for BFD64 64-bit offsetT). This is always
true and may result in a compile error when using compiler option
-Werror=type-limits, such as the one resolved with commit 6b8fb74a9403 ("gas: sframe: do not test whether offsetT exceeds
INT64_MIN..INT64_MAX") for BFD64 64-bit offsetT:
../../binutils-gdb/gas/gen-sframe.c: In function ‘get_offset_size_in_bytes’:
../../binutils-gdb/gas/gen-sframe.c:213:45: error: comparison is always true due to limited range of data type [-Werror=type-limits]
213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN))
| ^~
../../binutils-gdb/gas/gen-sframe.c:213:67: error: comparison is always true due to limited range of data type [-Werror=type-limits]
213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN))
| ^~
Instead of testing for whether the value is in range of
INT8_MIN..INT8_MAX, INT16_MIN..INT16_MAX, or INT32_MIN..INT32_MAX,
test whether the value is unchanged when casted to int8_t, int16_t,
or int32_t. This also improves readability.
gas/
* gen-sframe.c (get_offset_size_in_bytes): Simplify. Do not
test whether !BFD64 32-bit offsetT exceeds INT32_MIN..INT32_MAX.
Fixes: 58008ed4e6af ("gas: sframe: use standard min/max integer constants") Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Matthieu Longo [Fri, 25 Jul 2025 10:58:56 +0000 (11:58 +0100)]
py-gdb-readline: replace deprecated interfaces in GdbRemoveReadlineFinder
A previous patch [1] enabled readline in Python in a GDB-specific way
and blocked the standard Python readline module to prevent conflicts
with GDB by adding a custom importer raising an exception for the readline
module.
This custom importer was written back in 2012 for old Python versions,
and does not seem to work anymore with Python 3.x. find_module() and
load_module() have been deprecated since Python 3.4, and the first one
has been removed since 3.12, and the second will be removed in 3.15.
The GDB testsuite does not cover this use case, and the removal of
find_module() was not detected by the testsuite. This issue is tracked
in bug 32473.
importlib.abc.MetaPathFinder:
find_module(fullname, path)
Deprecated since version 3.4: Use find_spec() instead.
Changed in version 3.10: Use of find_module() by the import
system now raises ImportWarning.
Changed in version 3.12: find_module() has been removed. Use
find_spec() instead.
find_spec(fullname, path, target=None)
New in version 3.4, as a replacement for find_module.
importlib.abc.Loader:
load_module(fullname):
Deprecated since version 3.4, will be removed in version 3.15
The recommended API for loading a module is exec_module()
(and create_module()).
This patch uses Patryk Sondej's approach detailed in bug 32473, but with
a slight variation regarding the finder insertion in sys.meta_path.
It also adds a new test to prevent future regression.
H.J. Lu [Sun, 11 Jan 2026 03:43:40 +0000 (11:43 +0800)]
elf: Handle the section flag 'o' linked to special sections
Call _bfd_elf_section_from_bfd_section to get the sh_link value from
the section flag 'o' directive, which may point to special sections,
like SHN_ABS or SHN_COMM. Update readelf to print the special section
names in the sh_link field and replace "internal->sh_link > num" with
"internal->sh_link >= num".
bfd/
PR gas/33744
* elf.c (assign_section_numbers): Call
_bfd_elf_section_from_bfd_section to get the sh_link value.
binutils/
PR gas/33744
* readelf.c (special_defined_section_index): New.
(get_32bit_section_headers): Don't warn special section indexes
in the sh_link field.
(get_64bit_section_headers): Likewise.
(process_section_headers): Print special defined section names.
Jens Remus [Tue, 13 Jan 2026 13:14:43 +0000 (14:14 +0100)]
gas: sframe: do not test whether offsetT exceeds INT64_MIN..INT64_MAX
A value of type offsetT, which is either a signed 32-bit or 64-bit
integer, cannot exceed the range of INT64_MIN..INT64_MAX. This
resolves the following compile error:
../../binutils-gdb/gas/gen-sframe.c: In function ‘get_offset_size_in_bytes’:
../../binutils-gdb/gas/gen-sframe.c:213:45: error: comparison is always true due to limited range of data type [-Werror=type-limits]
213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN))
| ^~
../../binutils-gdb/gas/gen-sframe.c:213:67: error: comparison is always true due to limited range of data type [-Werror=type-limits]
213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN))
| ^~
Fixes: 58008ed4e6af ("gas: sframe: use standard min/max integer constants") Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Tue, 13 Jan 2026 12:17:49 +0000 (13:17 +0100)]
gas: sframe: use standard min/max integer constants
Replace the use of custom VALUE_{8|16|32|64}BIT constant definitions
with the standard INT{8|16|32|64}_{MIN|MAX} ones from stdint.h.
Besides improving readability this also fixes the issue that the
smallest representable signed 8/16/32-bit integer value was
erroneously sized as the next larger integer type. For example
get_offset_size_in_bytes (INT8_MIN) returned 2 instead of 1, due
to INT8_MIN (= -128) != -VALUE_8BIT (= -127):
Andrew Burgess [Fri, 9 Jan 2026 15:03:40 +0000 (15:03 +0000)]
gdb: more address styling throughout
I looked for the pattern 'gdb_puts (paddress (', these are places in
GDB where we are printing a target address without styling. I changed
most of what I found to print the address as styled.
I did leave a few unchanged in psymtab.c, these are all in maintenance
commands 'maint print psymbols', 'maint info psymtabs', and 'maint
check psymtabs'. None of these commands appear to print anything for
me (do we even use partial symtabs these days? I thought not) so I
didn't want to mess with commands that I couldn't test.
Other than the additional styling, there should be no user visible
changes after this commit.
Andrew Burgess [Fri, 9 Jan 2026 14:03:04 +0000 (14:03 +0000)]
gdb: output styling, and GDB code style fixes, for 'info frame'
I noticed that the output of 'info frame' was not styled much; the
frame's filename is styled, as are the names of any frame local
variables. But there's lots of address and line number styling
missing.
When I started looking at the info_frame_command_core function though,
there were lots of coding standard changes that could be made too, so
while I was in the area I thought I'd make some coding standard
changes to the function:
+ Inlined local variable declarations.
+ Removed the 'caller_pc_p' local, and made 'caller_pc' a
std::optional<CORE_ADDR> instead.
+ Converted a local from 'int' to 'bool'.
+ Replaced NULL with nullptr.
+ Replaced calls to gdb_printf with gdb_puts when the thing to print
is a constant string.
+ Added { ... } around if/else bodies that are a single statement
AND a comment inline with GDB coding style.
+ Avoid treating pointers and integers as booleans in 'if'
conditions. Compare to nullptr and/or zero instead.
Other than the new styling, there should be no user visible changes
after this commit.
Import the following commits from GCC as of r16-6728-g7c3584be8c8806: 07df546fb90 libiberty/testsuite: make test-pexecute's -t option a little more useful 0c775dcf3e7 libiberty: Make `objalloc_free' `free'-like WRT null pointer
H.J. Lu [Sun, 11 Jan 2026 22:55:34 +0000 (06:55 +0800)]
gas: Check @@@ before renaming the versioned symbol
The versioned symbol with the @@@ syntax is a special case. If the symbol
is not defined, 2 `@'s will be removed from the versioned_name. Otherwise,
1 `@' will be removed. But for malformed versioned symbols may not have
@@@:
Simon Marchi [Sun, 11 Jan 2026 03:40:30 +0000 (22:40 -0500)]
gdb/dwarf: make dwarf2_per_cu size fields atomic
Make m_addr_size, m_offset_size, and m_ref_addr_size use std::atomic.
Multiple indexer threads may set these values concurrently, which
currently causes a TSan failure:
It's fine for multiple threads to try to set these values concurrently.
The only condition is that either the previous value was 0 (unset) or
equals the new value being set.
Change-Id: Ib13218707cefdf33a51b3246ba5773a7800463b9
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33775 Reviewed-By: Tom de Vries <tdevries@suse.de>
Jens Remus [Mon, 12 Jan 2026 15:09:23 +0000 (16:09 +0100)]
gas: Explicitly code void parameter list
This fixes the following compile errors reported by Clang:
CC config/obj-elf-attr.o
../../gas/config/obj-elf-attr.c:64:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
64 | oav1_attr_info_init ()
| ^
| void
../../gas/config/obj-elf-attr.c:74:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
74 | oav1_attr_info_exit ()
| ^
| void
aarch64: Don't relax relocations to static function symbols
The aarch64 ABI states that long branch veneers may be added to
facilitate linking code that is beyond the range of a 26-bit call or
branch; but it requires that the target symbol be a function symbol.
Ensure that this latter condition is maintained by rejecting
relaxation of a static function symbol to it's section symbol.
Note that there should probably be a fix to the linker to enforce this
during link time. I've not done this for now because that might break
some existing object code that has been built with older versions of
gas. At some point we should revisit this.
This change also causes a small change in the LD testsuite: instead of
generating some veneers with the section name we now (correctly)
generate them using the name of the called function.
H.J. Lu [Fri, 9 Jan 2026 00:54:42 +0000 (08:54 +0800)]
x86: Cache the symbol table when packing relative relocations
When packing relative relocations, x86 linker may load the same symbol
table repeatedly, which can take a long time. On Intel Core i7-1195G7
with 32GB RAM, it takes more than 45 minutes to create an output with
-pie -z pack-relative-relocs from an input with 208025 code sections.
Cache the symbol table to reduce the link time to less than 2 seconds.
On the same machine, creating 3.1GB clang executable in LLVM 21.1.3 debug
build:
user 55.39 seconds
system 6.71 seconds
total 65.80 seconds
maximum set(GB) 10.43
page faults 2406941
PR ld/33765
* elfxx-x86.c (elf_x86_relative_reloc_record_add): Remove
keep_symbuf_p.
(_bfd_x86_elf_link_relax_section): Updated. Cache the symbol
table to avoid loading it again.
Tom de Vries [Sat, 10 Jan 2026 06:36:39 +0000 (07:36 +0100)]
[gdb/testsuite] Add missing wait in gdb.multi/sched-multi-add-inferior.exp
With a gdb build with -O0 and Address Sanitizer and test-case
gdb.multi/sched-multi-add-inferior.exp, I get:
...
FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \
continue to function1
FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \
continue to function2
FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \
continue to function1
FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \
continue to function2
FAIL: $exp: target_type_1=native: target_type_2=native: continue to function1
FAIL: $exp: target_type_1=native: target_type_2=native: continue to function2
...
In more detail, for the target_type_1 == target_type_2 == native configuration,
we have:
...
(gdb) continue^M
Continuing.^M
[Switching to Thread 0x7ffff7cc02c0 (LWP 2514714)]^M
^M
Thread 2.1 "sched-multi-add" hit Breakpoint 4, main (...) at multi-target.c:94^M
94 function2 (); /* set break 2 here */^M
(gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \
continue to function1
thread apply 2.1 set wait_for_gdb = 0^M
^M
Thread 2.1 (Thread 0x7ffff7cc02c0 (LWP 2514714) "sched-multi-add"):^M
(gdb) PASS: $exp: target_type_1=native: target_type_2=native: \
thread apply 2.1 set wait_for_gdb = 0
continue^M
Continuing.^M
[Switching to Thread 0x7ffff7cc02c0 (LWP 2514718)]^M
^M
Thread 3.1 "sched-multi-add" hit Breakpoint 3, main (...) at multi-target.c:93^M
93 function1 (); /* set break 1 here */^M
(gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \
continue to function2
...
The situation is as follows:
- there are two inferiors
- due to "set schedule-multiple on", continue continues both inferiors
- after the first continue, the test-case expects the breakpoint on thread 3.1
to trigger
- instead, the breakpoint in thread 2.1 triggers
The mechanism by which this order is supposed to be guaranteed, is that thread
2.1 is blocked, and only unblocked after thread 3.1 hits its breakpoint:
...
# Unblock thread 2.1 and continue again. This time, thread 2.1
# will hit a breakpoint.
gdb_test "thread apply 2.1 set wait_for_gdb = 0" ".*"
...
However, thread 2.1 is never blocked.
Fix this by adding the missing:
...
gdb_test "thread apply 2.1 set wait_for_gdb = 1" ".*"
...
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33540
Simon Marchi [Fri, 9 Jan 2026 19:41:24 +0000 (14:41 -0500)]
gdb/coffread: simplify stab section detection
We look for stab sections for the sole purpose of emitting a warning if
we see one. Simplify this by using a boolean to indicate if we saw a
stab section or not. Simplify the search to just look for sections
starting with ".stab", it should be enough for this purpose.
Also, remove the make_scoped_restore that would overwrite the stab
section vector, I'm not sure why it's there. It seems to me like it
would cause the warning to never be shown.
Change-Id: I56323189ffdaa2d06a96d457cdd999b23efa5979 Approved-By: Tom Tromey <tom@tromey.com>
gdb: update shared libraries when inferior is created, even if no bfd exists
I noticed an unexpected behaviour difference when loading a core file
in GDB depending on whether the main executable can be accessed or not.
If GDB knows about the main executable, then symbols for unrelated
libraries (such as libc) are loaded. If GDB cannot find the main
executable, then they are not.
Here is a reproducer using the artifacts from
gdb.python/py-missing-objfile.exp. This test is ideal to reproduce the
problem, because it hides from GDB the executable and library used to
generate the core file.
In the "good" case, where we give an executable to GDB (in addition to
the core), we get a complete backtrace (assuming GDB can find debug symbols
for glibc):
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.python/py-missing-objfile/hidden/py-missing-objfile -c testsuite/outputs/gdb.python/py-missing-objfile/py-missing-objfile.core -ex bt -batch
...
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007fcbd0c98a13 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:89
#2 0x00007fcbd0c3e410 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007fcbd0c2557a in __GI_abort () at abort.c:77
#4 0x000055561659d152 in dump_core () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:34
#5 0x000055561659d182 in main () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:46
Or, if debug symbols for glibc aren't available, GDB at least tells us
from which .so each frame comes from:
#0 0x00007fcbd0c9894c in ?? () from /usr/lib/libc.so.6
#1 0x00007fcbd0c3e410 in raise () from /usr/lib/libc.so.6
#2 0x00007fcbd0c2557a in abort () from /usr/lib/libc.so.6
#3 0x000055561659d152 in dump_core () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:34
#4 0x000055561659d182 in main () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:46
If we omit passing the main executable to GDB (and GDB has no way to
find it, because the test moved it on purpose), we get:
$ ./gdb -nx -q --data-directory=data-directory -c testsuite/outputs/gdb.python/py-missing-objfile/py-missing-objfile.core -ex bt -batch
#0 0x00007fcbd0c9894c in ?? ()
#1 0x0000000000000000 in ?? ()
Upon investigating, the "normal" path to load associated sos is through
the post_create_inferior function in infcmd.c, which calls
solib_create_inferior_hook. The solib_ops in turn loads the symbols by
calling solib_add.
When loading a core file, the list of loaded shared libraries can be
found (and as we can see with `info sharedlibraries`, this is done
properly). However, the current control flow handling in
post_create_inferior does not ask the solib to load the symbols through
solib_create_inferior_hook if a main exec_bfd is not present.
The proposed change eliminates the if statement in the
post_create_inferior function.
This change may have side-effects on some solib_ops which may not check
if the current inferior has a valid exec_bfd().
This commit also modifies the gdb.python/py-missing-objfile.exp test,
providing a test case in which the main exec file is missing, but not
the shared library. This is a good way to confirm this fix works, as
the symbols from the shared library should be found even though the main
exec file is missing. The test cases also ask GDB to clean_restart to
ensure there is no leftover bfd or symbols.
Furthermore, the total number of calls to the missing objfiles handler
is 4 in the "all objfiles missing" test case instead of the
previous 3 :
- 2 for the mapped files (exec and so), in
core_target_build_file_mappings
- 1 for the core file exec, in locate_exec_from_corefile_build_id
- 1 for the missing so, in solib_map_sections
The changes in check_loaded_debug handle the case where no symbol exist
at all, and also when a symbol table exists (but the symbol cannot be
found)
Note: Some comments in some solib_ops (frv, dbst) seem to indicate that
solib_add should be called before solib_create_inferior_hook by
post_create_inferior, but this does not seem to be the case anymore.
Those comments might need to be updated.
Change-Id: I517ff85813c941215b19fa8540c77f755a0aca28 Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tested-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
The warning comes from infcmd.c:post_create_inferior() which initializes
the solib_ops. The latter is in charge of calling solib_add() in its
implementation of solib_ops::create_inferior_hook. The svr4_solib_ops
class, however, does not call solib_add (through enable_break) if the
inferior is not being executed.
This patch moves the call to solib_add() outside of the conditional
nested call. No user-visible change should be expected, except for fact
that the warning will no longer be shown.
Change-Id: I5488dc166fdc985669422a0f1c0c2f43158cd8c4 Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdb/testsuite: fix typo in gdb.python/py-missing-objfile.exp
The py-missing-objfile.exp test attempts to load a core file with
missing debug info and counts the number of times a python missing
objfile handler is called.
In one test case, the number of expected calls to the missing objfile
handler is two, but the test case misleadingly says three. This commit
fixes this typo.
Change-Id: I421143ebed392227f14918ea529eb0e9cbd98dda Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Fri, 9 Jan 2026 17:46:56 +0000 (18:46 +0100)]
[gdb/symtab] Cache dw2_get_file_names result for dummy CU
Consider function dw2_get_file_names:
...
static struct quick_file_names *
dw2_get_file_names (dwarf2_per_cu *this_cu, dwarf2_per_objfile *per_objfile)
{
/* This should never be called for TUs. */
gdb_assert (!this_cu->is_debug_types ());
if (this_cu->files_read)
return this_cu->file_names;
If dw2_get_file_names_reader is called, the result is cached in
this_cu->file_names, and this fact is tracked in this_cu->files_read, allowing
subsequent calls to access the cached value.
But for dummy CUs, while the result (nullptr) is cached in
this_cu->file_names, this is not noted in this_cu->files_read, and
consequently subsequent calls will read the top-level DIE in the CU again.
Fix this by setting this_cu->files_read also for dummy CUs.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33777
Tom Tromey [Wed, 3 Dec 2025 18:20:53 +0000 (11:20 -0700)]
Show constants in DAP scopes output
This changes the DAP code so that constants will now be returned by a
DAP scopes request. This is perhaps slightly strange with Ada
enumerators, but on the other hand this is consistent with what the
CLI does.
Tom Tromey [Wed, 3 Dec 2025 14:07:20 +0000 (07:07 -0700)]
Allow DAP client to set Ada source charset at launch
A co-worker reported that certain symbols weren't appearing in the DAP
'scopes' response. In particular, symbols with non-ASCII names didn't
appear; though further research showed that this was in fact a result
of the variable in question actually being a constant.
Unfortunately Ada still requires the user to set the Ada source
character set in order to properly display symbol names. For DAP, it
seemed to make sense to allow this as a launch parameter. This patch
implements this.
Tom Tromey [Wed, 3 Dec 2025 14:48:00 +0000 (07:48 -0700)]
Explicitly use print_name in DAP
This changes some DAP code to explicitly use a symbol's print name.
Some places were using '.name'; and while 'str' does use the print
name, it seems better to be both consistent and explicit.
Jan Vrany [Fri, 9 Jan 2026 12:47:17 +0000 (12:47 +0000)]
gdb: install expanded_symbols_functions into objfiles created by JIT reader
This commit installs expanded_symbols_functions into objfiles created by
JIT reader API. This is needed so the JIT symbols can be used just like
any other symbols.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33554 Approved-By: Tom Tromey <tom@tromey.com>
Jan Vrany [Fri, 9 Jan 2026 12:47:17 +0000 (12:47 +0000)]
gdb: introduce expanded_symbols_functions
This commit adds new "quick" symbol functions, expanded_symbols_functions,
that work purely on examining objfile's compunits. This is useful for
example for JIT reader API where symbols are created by user-provided
code.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33554 Approved-By: Tom Tromey <tom@tromey.com>
Daniel Knezevic [Wed, 26 Nov 2025 11:23:25 +0000 (12:23 +0100)]
gdb: Make printing enum types prettier.
Update printing of enum types to follow the same formatting
conventions as for structs resulting in more readable output.
Now that horizontal space is less of an issue enum values are
always printed.
Empty enums are now printed with an added "<no enum values>"
message.
Example of printing an enum with default values:
enum class TestEnum {A, B, C, D};
(gdb) ptype TestEnum
type = enum class TestEnum : int {
TestEnum::A = 0,
TestEnum::B = 1,
TestEnum::C = 2,
TestEnum::D = 3
}
Example of printing an empty enum:
enum class TestEnum {};
(gdb) ptype TestEnum
type = enum class TestEnum : int {
<no enum values>
}
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19294 Approved-By: Tom Tromey <tom@tromey.com>
Hannes Domani [Fri, 9 Jan 2026 11:16:52 +0000 (12:16 +0100)]
Forget the last displayed sal when the referenced objfile is destroyed
When creating a new line-breakpoint after rerunning with a disabled or
removed breakpoint in a solib, you currently get this use-after-free
crash:
(gdb) break solib_main
Breakpoint 1 at 0x1030
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/outputs/gdb.base/solib-breakpoints-rerun/solib-breakpoints-rerun
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
Breakpoint 1, solib_main (arg=100) at /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/solib1.c:7
7 int ans = arg*arg; /* HERE */
(gdb) disable
(gdb) set confirm off
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/outputs/gdb.base/solib-breakpoints-rerun/solib-breakpoints-rerun
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[Inferior 1 (process 50868) exited normally]
(gdb) break 18
=================================================================
==50836==ERROR: AddressSanitizer: heap-use-after-free on address 0x7d65a543d488 at pc 0x55f022334c29 bp 0x7ffe9c7f45f0 sp 0x7ffe9c7f45e0
READ of size 8 at 0x7d65a543d488 thread T0
#0 0x55f022334c28 in symtab::filename() const ../../gdb/symtab.h:1747
#1 0x55f023a32b7d in create_sals_line_offset ../../gdb/linespec.c:2013
#2 0x55f023a37937 in convert_linespec_to_sals ../../gdb/linespec.c:2294
#3 0x55f023a3cf79 in parse_linespec ../../gdb/linespec.c:2652
#4 0x55f023a415b2 in location_spec_to_sals ../../gdb/linespec.c:3050
#5 0x55f023a423b0 in decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) ../../gdb/linespec.c:3126
#6 0x55f022826e1b in parse_breakpoint_sals ../../gdb/breakpoint.c:9069
#7 0x55f0228291c2 in create_breakpoint(gdbarch*, location_spec*, char const*, int, int, char const*, bool, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) ../../gdb/breakpoint.c:9312
#8 0x55f02282c298 in break_command_1 ../../gdb/breakpoint.c:9471
#9 0x55f02282d0bb in break_command(char const*, int) ../../gdb/breakpoint.c:9541
#10 0x55f022b05f56 in do_simple_func ../../gdb/cli/cli-decode.c:94
0x7d65a543d488 is located 904 bytes inside of 4064-byte region [0x7d65a543d100,0x7d65a543e0e0)
freed by thread T0 here:
#0 0x7f55aa91f79d in free /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:51
#1 0x55f0221f6403 in xfree<void> ../../gdb/../gdbsupport/gdb-xfree.h:37
#2 0x55f027b64851 in call_freefun ../../libiberty/obstack.c:103
#3 0x55f027b66283 in _obstack_free ../../libiberty/obstack.c:280
#4 0x55f0221f7a07 in auto_obstack::~auto_obstack() ../../gdb/../gdbsupport/gdb_obstack.h:126
#5 0x55f023f3dd83 in objfile::~objfile() ../../gdb/objfiles.c:509
#6 0x55f023f511d8 in std::default_delete<objfile>::operator()(objfile*) const /usr/include/c++/15.2.1/bits/unique_ptr.h:93
#7 0x55f023f4b8cd in std::unique_ptr<objfile, std::default_delete<objfile> >::~unique_ptr() /usr/include/c++/15.2.1/bits/unique_ptr.h:399
#8 0x55f0240b6dab in owning_intrusive_list<objfile, intrusive_base_node<objfile> >::erase(intrusive_list_iterator<objfile, intrusive_base_node<objfile> >) ../../gdb/../gdbsupport/owning_intrusive_list.h:113
#9 0x55f0240adb68 in program_space::remove_objfile(objfile*) ../../gdb/progspace.c:202
#10 0x55f023f3cfcf in objfile::unlink() ../../gdb/objfiles.c:409
#11 0x55f023f40faf in objfile_purge_solibs(program_space*) ../../gdb/objfiles.c:687
#12 0x55f02487ec19 in no_shared_libraries(program_space*) ../../gdb/solib.c:1359
#13 0x55f024b37e1e in target_pre_inferior() ../../gdb/target.c:2474
#14 0x55f0238ac7cd in run_command_1 ../../gdb/infcmd.c:381
#15 0x55f0238ae438 in run_command ../../gdb/infcmd.c:510
#16 0x55f022b05f56 in do_simple_func ../../gdb/cli/cli-decode.c:94
previously allocated by thread T0 here:
#0 0x7f55aa920cb5 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
#1 0x55f02241d780 in xmalloc ../../gdb/alloc.c:52
#2 0x55f027b6461f in call_chunkfun ../../libiberty/obstack.c:94
#3 0x55f027b649d1 in _obstack_begin_worker ../../libiberty/obstack.c:141
#4 0x55f027b650c5 in _obstack_begin ../../libiberty/obstack.c:164
#5 0x55f0221f775a in auto_obstack::auto_obstack() ../../gdb/../gdbsupport/gdb_obstack.h:123
#6 0x55f023f39c91 in objfile::objfile(gdb::ref_ptr<bfd, gdb_bfd_ref_policy>, program_space*, char const*, enum_flags<objfile_flag>) ../../gdb/objfiles.c:257
#7 0x55f023f3ccaa in objfile::make(gdb::ref_ptr<bfd, gdb_bfd_ref_policy>, program_space*, char const*, enum_flags<objfile_flag>, objfile*) ../../gdb/objfiles.c:392
#8 0x55f02498b1d2 in symbol_file_add_with_addrs ../../gdb/symfile.c:1069
#9 0x55f02498c099 in symbol_file_add_from_bfd(gdb::ref_ptr<bfd, gdb_bfd_ref_policy> const&, char const*, enum_flags<symfile_add_flag>, std::vector<other_sections, std::allocator<other_sections> >*, enum_flags<objfile_flag>, objfile*) ../../gdb/symfile.c:1156
#10 0x55f02487255b in solib_read_symbols(solib&, enum_flags<symfile_add_flag>) ../../gdb/solib.c:660
#11 0x55f024876c0c in solib_add(char const*, int, int) ../../gdb/solib.c:993
#12 0x55f02487f1f8 in handle_solib_event() ../../gdb/solib.c:1399
#13 0x55f0227df91f in bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const&, bpstat*) ../../gdb/breakpoint.c:5962
#14 0x55f023944fa8 in handle_signal_stop ../../gdb/infrun.c:7130
#15 0x55f02393e2a1 in handle_inferior_event ../../gdb/infrun.c:6574
#16 0x55f0239279f2 in fetch_inferior_event() ../../gdb/infrun.c:4713
#17 0x55f023885fe3 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:42
#18 0x55f023af706e in handle_target_event ../../gdb/linux-nat.c:4449
#19 0x55f027c2d2f0 in handle_file_event ../../gdbsupport/event-loop.cc:551
#20 0x55f027c2e4ff in gdb_wait_for_event ../../gdbsupport/event-loop.cc:672
It happened because last_displayed_symtab_info of stack.c still contained
a reference to a symtab that was already freed in the 2nd run.
This fixes it by clearing last_displayed_symtab_info in the objfile
destructor, if it is pointing to that objfile.
Now setting of the 2nd breakpoint works:
(gdb) break 18
Breakpoint 2 at 0x555555555141: file /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/so-impl-ld.c, line 18.
(gdb)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32668 Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Richard Earnshaw [Tue, 16 Dec 2025 14:08:10 +0000 (14:08 +0000)]
aarch64: Fix out-of-range branch veneers when --fix-cortex-a53-843419
The erratum mitigation support for the Cortex-A53 843419 erratum
inserts a new stub for every possible instance of the erratum. Since
each stub ends up inserting 4k of space into the binary, in order to
avoid perturbing the alignment of other potential erratum sequences we
can end up adding substantially more space than the distance to the
next long-branch stub that we've prepared for.
The problem is, fundamentally a phase ordering problem, but that's
easily resolvable by running the 843419 erratum pass first and then
creating the stub groups once that is done. In this way we take into
account the additional padding when forming the groups to ensure that
they remain within range.
Richard Earnshaw [Tue, 16 Dec 2025 14:04:10 +0000 (14:04 +0000)]
aarch64: Use section names for empty stub symbols
If the target symbol for a stub was empty we would previously end up
using an anonymous stub name of the form ___veneer. To make things a
little clearer use the section symbol for the target section in this
case. We now end up with veneer symbols like __.text_veneer.
Jan Beulich [Fri, 9 Jan 2026 07:43:38 +0000 (08:43 +0100)]
bfd: avoid elf-properties.c for ELF-free targets
It is absurd to build this file when it's not possibly used. Move its
references to where other elf-*.* are and introduce a compiler define
(paralleling what gas uses, as having the same purpose) to isolate out
ELF-specific pieces in compress.c (which is where the references into
elf-properties.c are coming from).
Jan Beulich [Fri, 9 Jan 2026 07:39:14 +0000 (08:39 +0100)]
ld/ELF: suppress note section rearrangement for relocatable linking
Input sections would generally best retain their order from in the
input(s) or relocatable links. In particular the (odd) sorting of note
sections by alignment is entirely unnecessary there, and could potentially
even be harmful. Simply accumulate orphan sections in the order observed.
Of course this has an effect on section order, so a few testsuite
adjustments are necessary. The test for PR ld/27590 is being relaxed, as
it's no clear why sh_link fields would need to have exact expectations
when at the same time section numbers aren't matched. (Obviously the .rela
sections should match their corresponding data sections', but afaict this
cannot be [easily] expressed.) Xstormy16 XFAILs for a few tests can be
dropped as the sections of interest there are orphan ones, and hence now
are placed independent of the linker scripts unusual placing of .data
ahead of .text.
Simon Marchi [Thu, 8 Jan 2026 19:33:26 +0000 (14:33 -0500)]
gdb/xcoffread: stylistic cleanup
Do a few cleanups:
- declaring variables where they are used
- rename functions to be more precise
- add explicit comparison against nullptr or 0
- remove struct/union keywords
- remove or update outdated comments
Change-Id: I3f9e8604f79ee4d36cbe3d65079cb23051fcc703 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 8 Jan 2026 19:33:24 +0000 (14:33 -0500)]
gdb/xcoffread: simplify xcoff_secnum_to_sections
The only remaining caller of xcoff_secnum_to_sections doesn't care about
the section index in the objfile, so remove that part.
Return the BFD section as the return value of the function, instead of
an output parameter. Remove the unnecessary default in the switch, to
avoid a "jump to label over variable initialization" warning.
Rename to xcoff_secnum_to_section (singular).
Change-Id: I464d8b0e1425ea2732b0d61355c5b0c66218122e Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 8 Jan 2026 19:33:23 +0000 (14:33 -0500)]
gdb/xcoffread: allocate symbol table using vector in scan_xcoff_symtab
The symbol table content is only needed for the duration of
scan_xcoff_symtab, so it's not necessary to allocate it on the objfile
obstack. Switch to using a vector that is freed at the end of the
function.
Change-Id: Ib5acdea460969300a92816a3e71b7d82c80faebf Approved-By: Tom Tromey <tom@tromey.com>
It is not necessary to save the symbol table content and number of
symbols in xcoff_symfile_info, because they are only needed for the
duration of scan_xcoff_symtab.
Move the reading of the symbol table content to scan_xcoff_symtab, and
keep everything as local variables.
Change-Id: I21e2b95a0b8df2255ba46904083658a4e8cb89f0 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 8 Jan 2026 19:33:19 +0000 (14:33 -0500)]
gdb/xcoffread: remove name computation
It is no longer necessary to get names of symbols. The only thing we
are interested in is the symbol to get the TOC offset, for which the
name doesn't matter.
Change-Id: I47e6009ed7600ea9c412fb25ed21a295cd0fec49 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Thu, 8 Jan 2026 21:11:08 +0000 (14:11 -0700)]
Fix error case in coffread.c
coffread.c is the last spot (that I know of) that incorrectly calls
perror_with_name when a BFD function fails. The issue here is that
perror_with_name examines errno, but BFD failures do not set this.
This patch changes this to use error and bfd_errmsg.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31041 Approved-By: Simon Marchi <simon.marchi@efficios.com>
Indu Bhagat [Thu, 8 Jan 2026 20:11:17 +0000 (12:11 -0800)]
gas: sframe: fix PR gas/33756
Previously, sframe_xlate_do_remember_state () relied exclusively on
last_fre (the last Frame Row Entry for the previous PC range block). At
the start of a function (before an advance in location), last_fre is
NULL. The intent of DW_CFA_remember_state, however, is to simply
snapshot the state of the call frame information at the time. In terms
of SFrame generation, this means that we should simply look at cur_fre
(the scratchpad FRE currently being built from initial CFI
instructions in the current context).
Remove the common-empty-1.s which assumed that .cfi_startproc,
immediately followed by a .cfi_remember_state is not present out in the
wild. Its best to not make such an assumption, as such a sequence is
valid CFI, FWIW.
Initial CFI are arch-specific, so add a new testcase for x86_64 to check
.cfi_remember_state handling for SFrame is sensible. While at at, also
add a new testcase for s390x.
Co-Authored-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
PR gas/33756
* gen-sframe.c (sframe_xlate_do_remember_state): Use cur_fre.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Adjust common-empty-1 test to
be repurposed as cfi-sframe-x86_64-pr33756. Add s390x testcase.
* gas/cfi-sframe/common-empty-1.d: Removed.
* gas/cfi-sframe/common-empty-1.s: Removed.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33756.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33756.s: New test.
* gas/cfi-sframe/cfi-sframe-s390x-pr33756.d: New test.
* gas/cfi-sframe/cfi-sframe-s390x-pr33756.s: New test.
Tom Tromey [Thu, 8 Jan 2026 14:48:21 +0000 (07:48 -0700)]
Remove two fields from xcoff_symfile_info
Inspection shows that xcoff_symfile_info::min_lineno_offset and
xcoff_symfile_info::max_lineno_offset are never really used. Removing
this then shows that find_linenos doesn't do any useful work. So,
remove the fields and this function.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Thu, 8 Jan 2026 16:15:50 +0000 (09:15 -0700)]
Include libiberty.h in bfdio.c
On my Fedora 41 machine, a cross-hosted mingw build fails with:
../../binutils-gdb/bfd/bfdio.c:249:50: error: implicit declaration of function 'ARRAY_SIZE'; did you mean 'ARRAYSIZE'? [-Wimplicit-function-declaration]
Including libiberty.h in bfdio.c fixes the failure.
Tom Tromey [Wed, 7 Jan 2026 16:49:13 +0000 (09:49 -0700)]
Remove sym_fns::sym_read_linetable
The last user of sym_fns::sym_read_linetable was xcoffread.c. Now
that the code there has been removed, this callback can be removed as
well. This slightly simplifies buildsym.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Tue, 6 Jan 2026 00:19:35 +0000 (17:19 -0700)]
Remove sym_fns::sym_finish
sym_finish::sym_finish isn't needed by any existing code, so this
patch removes it.
Note that it should never be needed again. It's much cleaner, IMO,
for symbol readers to attach data to the objfile or per-BFD via the
registry. Then, any cleanup will be automatic.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Wed, 7 Jan 2026 16:36:00 +0000 (09:36 -0700)]
Remove dead code from xcoffread.c
This removes a lot of obviously dead code from xcoffread.c. There are
some unused macros and types. A few globals can be removed because
they are never assigned to or really used for anything.
projects / thirdparty / binutils-gdb.git / log
