A previous commit added new backend hook sframe_support_flex_fde_p by
defining a new function for each backend that supports SFrame stack
trace format:
As pointed out in a review comment, simply providing the definition to
use true/false (as applicable) is sufficient for the purpose, and helps
generate better code. So do that.
https://inbox.sourceware.org/binutils/80404871-53b4-4f5c-9d86-7a3a4d0a920e@suse.com/
GNU doesn't generally use the "<...>" convention, but instead uses
upper case for "metasyntactic variables". See the GNU coding
standards for this topic.
In this particular spot, though, I think the old form using quotes is
preferable. This patch reverts this change.
Commit a1c2fa92ac93bf50227941bd82094e6997c5fd56 broke the ld
testcase for .note.GNU-stack wanting to be SHT_NOTE. Fix this
by falling back to .text if .dynamic isn't available to define
the text segment base.
2026-01-21 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf64_hppa_late_size_sections): Fallback
to .text if .dynamic section isn't found.
Tom de Vries [Wed, 21 Jan 2026 15:43:07 +0000 (16:43 +0100)]
[gdb] Ignore .sframe section in dtrace_static_probe_ops::get_probes
On aarch64-linux (Debian testing), with test-case gdb.base/fission-macro.exp I
run into:
...
(gdb) set complaints 5^M
(gdb) file fission-macro-v4-b32-s0^M
Reading symbols from fission-macro-v4-b32-s0...^M
During symbol reading: \
skipping section '.sframe' which does not contain valid DOF data.^M
(gdb) FAIL: $exp: lang=c: dwarf_version=4: dwarf_bits=32: strict_dwarf=0: \
No complaints
...
The problem is that there's an overlap between:
...
./include/elf/common.h:#define SHT_SUNW_dof 0x6ffffff4
...
and:
...
./include/elf/common.h:#define SHT_GNU_SFRAME 0x6ffffff4
...
So when dtrace_static_probe_ops::get_probes tries reading an SHT_SUNW_dof
section, it fails to read the corresponding magic number and bails with this
complaint:
...
During symbol reading: \
skipping section '.sframe' which does not contain valid DOF data.^M
...
But the section actually being read is not an SHT_SUNW_dof section, but an
SHT_GNU_SFRAME section:
...
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[17] .sframe GNU_SFRAME 00000000000008f0 0008f0 000035 00 A 0 0 8
...
Fix this by checking for the section name .sframe in
dtrace_static_probe_ops::get_probes.
Tested on aarch64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33813
Michal Sobon [Wed, 21 Jan 2026 13:45:05 +0000 (14:45 +0100)]
opcodes: Fix BMASKI disassembly for immediate 32 on M*Core
The BMASKI instruction has three encoding variants (OMa, OMb, OMc).
The OMa encoding (0x2C00, mask 0xFFF0) specifically represents
BMASKI with immediate 32, encoded as IMM5=0.
Per Motorola M*Core specification: "An IMM5 value of 0 is interpreted
as a value of 32."
Previously, all three variants extracted the immediate the same way,
causing OMa to incorrectly display 0 instead of 32.
opcodes/
* mcore-dis.c (print_insn_mcore): Handle OMa encoding to display
immediate 32 instead of 0 for BMASKI.
gas/testsuite/
* gas/mcore/allinsn.s: Add test for bmaski with immediate 32.
Replace two clrc padding instructions with one for 4-byte alignment.
Fix missing newline at end of file.
* gas/mcore/allinsn.d: Update expected output.
Evgeny Karpov [Wed, 21 Jan 2026 13:44:44 +0000 (14:44 +0100)]
aarch64: Add bigobj support to AArch64 COFF
During Boost library testing on aarch64-w64-mingw32, it appeared that 2^16
sections are not enough. It can be handled by using the bigobj format to extend
the total amount of sections to 2^32. This patch adds bigobj support to
AArch64 COFF in a similar way to how it is done for x86_64.
Co-authored-by: Martin Vejbora <mvejbora@microsoft.com> Signed-off-by: Evgeny Karpov <evgeny@kmaps.co>
Jan Beulich [Wed, 21 Jan 2026 13:43:54 +0000 (14:43 +0100)]
ld: testcase for .note.GNU-stack wanting to be SHT_NOTE
If --noexecstack is removed and instead of empty.s a source file is used
which explicitly creates a @progbits .note.GNU-stack, the test fails (for
the absence of a NOTE segment).
Jan Beulich [Wed, 21 Jan 2026 13:42:39 +0000 (14:42 +0100)]
readelf: don't (silently) fail on empty SHT_NOTE sections
Them containing no entries is not an error. Such sections simply have
nothing to dump. (Exiting with non-zero status but no error message isn't
quite appropriate anyway.)
Matthieu Longo [Thu, 4 Dec 2025 15:50:30 +0000 (15:50 +0000)]
aarch64: silence GCS warnings on shared libraries for -z gcs=implicit
Dynamic library incompatibilities should not be reported when no GCS
option is provided (defaults to '-z gcs=implicit') and no explicit
diagnostic is provided via '-z gcs-report-dynamic'.
Binary Linux distributions do not rebuild all packages from scratch
when rolling out a new feature or creating a new release; only
modified packages get rebuilt. In the context of GCS deployment, this
meant that some packages were rebuilt with GCS enabled while their
dependencies were not yet GCS-compatible, resulting in warnings. These
warnings caused build failures for packages that treat linker warnings
as errors. Those errors slowed down the GCS deployment, and Linux
distribution maintainers requested that no GCS option provided should
be equivalent to '-z gcs=implicit -z gcs-report-dynamic=none'.
In contrast, '-z gcs=always' should continue to report such issues by
default. Warnings can still be disabled or promoted to errors by
explicitly setting '-z gcs-report-dynamic' to respectively 'none' or
'error'.
This patch preserves the existing behaviour for '-z gcs=never', changes
the default behaviour of '-z gcs=implicit' or no GCS option, and removed
the inheritance mechanism between '-z gcs-report' and '-z gcs-report-dynamics'.
The expected behaviour with the different possible combinations is as
follows:
* -z gcs=never:
No diagnostic messages are emitted.
* -z gcs=implicit:
No diagnostic messages are emitted for input static objects.
However, if all the input static objects are marked for GCS, the
output object will also be marked for GCS.
In this case the output is marked with GCS, '-z gcs-report-dynamic'
defaults to 'none' and no diagnostics are emitted. Diagnostics can
be enabled by explicitly providing the option.
* -z gcs=always:
Warning diagnostics for both static and dynamic input objects are
enabled by default. The two options are independent of one another,
and the diagnostic level can be adjusted for each by explicitly
providing the desired level to '-z gcs-report-dynamic' and '-z
gcs-report'.
The patch also updates the existing tests, removes redundant test cases,
and adds new tests covering cases with no report option provided, or
report options explicitly set.
The SFrame test for PR ld/33401 is a two-step link test where the
second link depends on the output of the first. In the first step, the
linker process generates R_*_NONE relocs for .sframe section, while
the second link process should pass without any issue.
This patch reworks the PR ld/33401 test by removing the call to
run_cc_link_tests, and use individual command invocation for
compilation, assembling and linking. It introduces the UNRESOLVED
status if the first step contains a linking or assembling error. The
UNTESTED status is emitted if the first stage doesn't produce R_*_NONE
relocs in .sframe section to test the original issue.
ld/
PR ld/33784
* testsuite/ld-sframe/sframe.exp (check_pr33401): Rework the
procedure for UNRESOLVED and UNTESTED cases.
(check_dump): New procedure.
* testsuite/ld-sframe/pr33401.rd: Add extra line at the end of the
file.
As a result of the mail exchange in
https://sourceware.org/pipermail/binutils/2026-January/147439.html,
the run_cc_link_test procedure may want to link standard libs
too. However, this is not required for running PR 32789 tests. Add
-nostdlib option.
ld/
* testsuite/ld-sframe/sframe.exp: Add nostdlib when testing PR
32789.
Alan Modra [Mon, 19 Jan 2026 22:13:25 +0000 (08:43 +1030)]
libsframe misaligned uint32_t
I saw asan complaints about misaligned loads and stores when taking a
quick look at pr33810 before Jens' patch was applied. They have
disappeared now, but it looks to me like a FRE can start on any
address boundary and there is no padding or suchlike to align the
FRE fields.
* sframe.c (flip_fre_stack_offsets): Let the compiler know
that integers may be misaligned.
Simon Marchi [Sat, 17 Jan 2026 06:02:35 +0000 (01:02 -0500)]
gdb/dwarf: add unit_lists structure to index writer
I think it makes the code more readable than the pair of vector. Also,
I'm considering adding a third list (foreigh type units), which will be
easier with the structure.
Change-Id: I38ec4ddf8f786a2ba10c5b371cfe04c2baaa7da9 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 17 Jan 2026 06:02:32 +0000 (01:02 -0500)]
gdb/dwarf: move DWP htab nullptr check to lookup_dwo_unit_in_dwp
cutu_reader::lookup_dwo_cutu gets hold of the right htab for the kind of
unit to look up (CU or TU), but then just uses the pointer to know if it
should call lookup_dwo_unit_in_dwp or not. lookup_dwo_unit_in_dwp then
uses the same condition to obtain the correct htab. I think it would
make more sense to return early from lookup_dwo_unit_in_dwp instead, if
the required htab does not exist.
Change-Id: I6f8f96aba2452f8261b3c60667e72fb21b97c89d Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 20 Jan 2026 15:08:38 +0000 (15:08 +0000)]
gdb: fail for 'maint print frame-id LEVEL' of an invalid frame
I noticed that 'maint print frame-id LEVEL' will always print a
frame-id, just not always for LEVEL, for example:
(gdb) bt
#0 woof () at stack.c:4
#1 0x000000000040111f in bar () at stack.c:10
#2 0x000000000040112f in foo () at stack.c:16
#3 0x000000000040113f in main () at stack.c:22
(gdb) maintenance print frame-id 4
frame-id for frame #3: {stack=0x7fffffffa640,code=0x0000000000401131,!special}
(gdb)
Notice that the request was for the frame-id of #4, which doesn't
exist, but what I got was the frame-id for #3.
Fix this by adding a check to maintenance_print_frame_id (frame.c), so
the new behaviour is:
(gdb) maintenance print frame-id 4
No frame at level 4.
(gdb)
This matches the behaviour of the 'frame' command:
(gdb) frame 4
No frame at level 4.
(gdb)
I've added a new test to cover this case.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
hppa64: Improve relocation handling for local symbols and add gc_section support
With this patch, gcc-16 can be built and there are significant
improvements in test results. I spent a lot of time trying to
fix the EH exception support. While there are still issues with
handling relocations in linkonce sessions, exception handling
mostly works if pc-relative and text relative encoding is used
in .eh_frame. The main problems are the HP-UX dynamic linker
relocates the text and data segements indpendently, and it does
not support unaligned dynamic relocations.
Due to a configure bug in libstdc++-v3, the lack of gc_section
support caused many test failures, so I added the gc_section
support form elf32-hppa.c.
I also move the HP_LOAD_MAP scratchpad to the end of the .bss
section and fixed a number of issues with the linker scripts.
2026-01-20 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf64_hppa_check_relocs): Drop NEED_PLT
from R_PARISC_LTOFF_FPTR relocations. Revise R_PARISC_FPTR64
relocation to use maybe_dynamic. Add support for
R_PARISC_GNU_VTINHERIT and R_PARISC_GNU_VTENTRY relocations.
Add code to handle dynamic relocations of local symbols.
(elf64_hppa_gc_mark_hook): New.
(ensure_undef_dynamic): New.
(allocate_dynrel_entries): Revise checks to determine when
to discard relocs.
(elf64_hppa_late_size_sections): Revise allocation of local
PLT, DLT and OPD entries.
(elf64_hppa_finalize_opd): Remove assert.
(elf64_hppa_finalize_dlt): Change type of dynindx to long.
(elf64_hppa_finalize_dynreloc): Likewise. Add check for
discarded sections. Correct handling of R_PARISC_FPTR64
relocation. Remove assert. Add new assert to check that
we don't allocate more relocs in .rela.data than it can
hold.
(elf64_hppa_finish_dynamic_sections): Move allocation for
DT_HP_LOAD_MAP to end of .bss section. Only allocate on
HP-UX.
(elf_hppa_dlt_dynrel_reloc): Add dynrel_type argument.
Change type of dynindx. Drop use of value. Remove assert.
(elf_hppa_opd_dynrel_relocs): Rename to elf_hppa_opd_eplt_reloc.
Drop code to to emit R_PARISC_FPTR64 relocation.
(elf_hppa_opd_fptr_reloc): New.
(elf_hppa_final_link_relocate): Add SYM arguement. Move
check for SEC_DEBUGGING. Rework DLT, LTOFF, FPTR and DIR64
relocation handling.
(elf64_hppa_relocate_section): Add asserts to ensure symbol
isn't undefined and input_section hasn't been discarded.
(elf_backend_gc_mark_hook): Define.
(elf_backend_can_gc_sections): Define.
ld/ChangeLog:
* emulparams/elf64hppa.sh (DATA_ADDR): Revise value to match
HP-UX 11 value.
(SHLIB_DATA_ADDR): Likewise.
(NOP): Define.
(OTHER_READONLY_SECTIONS): Add .data.rel, .HP.init, .preinit,
.init and .fini sections to list.
(__SYSTEM_ID_D, __TLS_SIZE_D, __FPU_REVISION, __FPU_MODEL,
__CPU_REVISION, __CPU_KEYBITS_1, __LOAD_INFO, __ARGC, __ARGV,
__ENVP, __libdl_jmp_tbl, __systab): Provide.
(DATA_START_SYMBOLS, OTHER_SYMBOLS, INIT_START): Delete.
(PREINIT_START, PREINIT_END, INIT_START): Define.
emulparams/hppa64linux.sh (NOP): Define.
(DATA_START_SYMBOLS): Delete.
scripttempl/elf64hppa.sc: Delete .init and .fini sections
from script. Allocate 16 bytes at end of .bss for HP_LOAD_MAP.
Tom Tromey [Thu, 8 Jan 2026 15:03:33 +0000 (08:03 -0700)]
Move puts_tabular to obj-lang.c
Only objc-lang.c uses puts_tabular. This patch moves the function
there and makes it 'static'. It is also updated not to depend on the
global (but private to utils.c) chars_printed, and not to call
begin_line.
Tom Tromey [Fri, 16 Jan 2026 18:27:46 +0000 (11:27 -0700)]
Remove all globals from coffread.c
This patch changes coffread.c to add a reader object type. All
globals are moved into this type, and the majority of functions in
coffread.c are changed to be methods.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 16 Jan 2026 18:18:20 +0000 (11:18 -0700)]
Use coffread_objfile throughout coffread.c
coffread.c:coff_symtab_read sets a global objfile while working. It
seemed nicer to me to hoist this so that it is set by the main entry
point, and then used throughout the file.
Normally I wouldn't encourage the use of globals, but shortly we'll be
replacing these with an object.
Note that while coff_symtab_read cleared coffread_objfile when it was
finished, I haven't preserved this in the new patch. First, this
should have been done with a scoped_restore. Second, this is the only
global to get this treatment. Third, it's not necessary at all. And,
finally, this will be moot anyway when the globals are removed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 16 Jan 2026 18:08:58 +0000 (11:08 -0700)]
Remove redundant nlist_bfd_global
coffread.c has two BFD globals: nlist_bfd_global and symfile_bfd.
There's no need for both, and since symfile_bfd is set early (in
coff_symfile_read, the entry point), this removes nlist_bfd_global and
replaces all the uses.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
BFD: Remove extraneous BFD struct member setup from `bfd_make_readable'
Complementing commit 3097045a18a8 ("ld plugin bfd_make_readable leak")
remove assignments to BFD struct members from `bfd_make_readable' that
now duplicate ones unconditionally made by `_bfd_free_cached_info'
called earlier on.
BFD: Remove null pointer checks for `bfd_hash_table_free' calls
Given that as from commit 90e5645309be ("libiberty: Make `objalloc_free'
`free'-like WRT null pointer") `bfd_hash_table_free' now returns with no
action taken when called for a hash table with no allocation present,
remove null pointer checks guarding invocations.
Jens Remus [Tue, 20 Jan 2026 09:33:56 +0000 (10:33 +0100)]
s390: gas: Remove support for register names "ap" and "cc" in CFI directives
The assembler erroneously converted the special register names "ap" and
"cc" to the DWARF register numbers 32 and 33 respectively, which are
actually assigned to the control registers c0 and c1 according to both
the s390 32-bit (s390) ELF ABI [1] and s390 64-bit (s390x) ELF ABI [2].
Register numbers 32 and 33 are used internally by GCC as "argument
pointer" (ap) and "condition code" (cc). Very early GCC versions leaked
this out into DWARF. However, those GCC-internal special register names
should never be actually used in CFI, especially given their resulting
DWARF register numbers have a different meaning in DWARF (CFI).
Jens Remus [Tue, 20 Jan 2026 09:33:56 +0000 (10:33 +0100)]
s390: gas: Support access register names in CFI directives
Convert access register (AR) names a0-a15 to DWARF register numbers when
used in CFI directives. Convert an access register number (0..15) to
its corresponding DWARF register number (48..63) as specified in the
s390 64-bit (s390x) ELF ABI [1] by adding 48.
gas/testsuite/
* gas/s390/cfi-regnames.d: Add test for AR names in in CFI
directives.
* gas/s390/cfi-regnames.s: Likewise.
* gas/s390/cfi-regnames-err.l: Likewise.
* gas/s390/cfi-regnames-err.s: Likewise.
Jens Remus [Tue, 20 Jan 2026 09:33:56 +0000 (10:33 +0100)]
s390: gas: Support vector register names in CFI directives
Convert vector register names v0-v31 to DWARF register numbers when used
in CFI directives. Convert a vector register number (0..31) to its
respective DWARF register number (16..31, 68..83) as specified in the
s390 64-bit (s390x) ELF ABI [1] as follows:
Right rotate the least significant three bits and add 16 for register
numbers 0..15 or 68 for register numbers 16..31.
Add a test case for the use of vector register (VR) names in CFI
directives.
Jens Remus [Tue, 20 Jan 2026 09:33:55 +0000 (10:33 +0100)]
s390: gas: Fix conversion of FP register names to DWARF register numbers
The assembler supports register names in CFI directives. For floating-
point (FP) registers f0..f15 the register numbers 0..15 are erroneously
converted to DWARF register numbers 16..31 by adding 16. This is wrong
as the s390 64-bit (s390x) ELF ABI [1] specifies the DWARF register
numbers for the FP registers as follows:
Convert a FP register number (0..15) to its respective DWARF register
number (16..31) as follows:
Right rotate the least significant three bits and add 16.
Add a test case for the use of general register (GR; r0..r15) and
floating-point register (FPR; f0..f15) names in CFI directives.
gas/
* config/tc-s390.c (tc_s390_regname_to_dw2regnum): Fix
conversion of FP register names to DWARF register numbers.
gas/testsuite/
* gas/s390/s390.exp (cfi-regnames, cfi-regnames-err): Run new
tests.
* gas/s390/cfi-regnames.d: New test for GR and FPR names in CFI
directives.
* gas/s390/cfi-regnames.s: Likewise.
* gas/s390/cfi-regnames-err.l: Likewise.
* gas/s390/cfi-regnames-err.s: Likewise.
Jens Remus [Tue, 20 Jan 2026 09:22:52 +0000 (10:22 +0100)]
libsframe: use proper FRE type when flipping SFrame V3 FREs
flip_sframe_fdes_with_fres_v3 was erroneously using a fixed FRE type
of 0 (= SFRAME_FRE_TYPE_ADDR1) when endianness byte-flipping the FREs,
regardless of the actual FRE type (i.e. ADDR1, ADDR2, or ADDR4). This
only affected cross builds, where the .sframe section data may needed
to be endianness byte-flipped (e.g. binutils cross-built for s390
64-bit (s390x) on x86-64).
As a consequence objdump/readelf with option --sframe could fail to dump
e.g. s390 64-bit (s390x) .sframe section data on x86-64 with the
following error message:
Error: SFrame decode failure: Buffer does not contain SFrame data.
The linker ld-sframe test "PR ld/33401 (Step 1: Create relocatable
object and check R_*_NONE)" cross-build for s390 64-bit (s390x) on
x86-64 could fail with ld error message:
error in tmpdir/StatePlaying.o(.sframe); no .sframe will be created
The linker ld-sframe test "PR ld/33401 (Step 1: Create relocatable
object and check R_*_NONE)" cros-build for s390 64-bit (s390x) on
x86-64 could fail with BDF assertion:
Add a common cfi-sframe assembler test, that forces a FDE type of
SFRAME_FRE_TYPE_ADDR2. When the test is run cross-build it may
exercise the SFrame FDE and FDE endianness byte flipping.
libsframe/
PR ld/33810
* sframe.c (sframe_decode_fde_attr_v3): Decode and return FRE
type from FDE attributes.
(flip_sframe_fdes_with_fres_v3): Use proper FRE type from
FDE attributes when flipping FREs.
gas/testsuite/
PR ld/33810
* gas/cfi-sframe/cfi-sframe.exp (cfi-sframe-common-pr33810): Run
new test.
* gas/cfi-sframe/cfi-sframe-common-pr33810.d: New test.
* gas/cfi-sframe/cfi-sframe-common-pr33810.s: Likewise.
Bug: https://sourceware.org/pr33810 Fixes: 8ab6e4c72ab6 ("[SFrame-V3] include: gas: libsframe: split FDE into idx and attr") Reported-by: Alan Modra <amodra@gmail.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Tom de Vries [Tue, 20 Jan 2026 08:06:20 +0000 (09:06 +0100)]
[gdb] Add regression test for PR symtab/33777
PR symtab/33777 reports a problem where toplevel DIEs of partial units are
read many times.
The problem manifest as a timeout when building gdb with -O0 and Asan, and
running test-case gdb.base/tls-dlobj.exp with glibc debuginfo installed.
Reproduce the problem in a simpler and quicker way, without relying on glibc
debuginfo:
- build an executable with 100 partial units
- run info line "$file:$line" a 100 times
- add a line to "maint print statistics" that tells us how many time a
toplevel DIE is read.
Without the fix we have:
...
Number of read units: 1
Number of unread units: 108
Number of read top-level DIEs: 10118
...
and with the fix we have:
...
Number of read units: 1
Number of unread units: 108
Number of read top-level DIEs: 218
...
Detect the problem by asserting:
...
gdb_assert { $top_level_die <= 3 * ( $read_cu + $unread_cu ) }
...
The factor 3 is used because for some target boards $top_level_die is slightly
more than 2 * ( $read_cu + $unread_cu ).
Tom Tromey [Sun, 18 Jan 2026 17:42:34 +0000 (10:42 -0700)]
Remove "alias" hack from add_symbol_to_list
add_symbol_to_list has this code:
/* If this is an alias for another symbol, don't add it. */
if (symbol->linkage_name () && symbol->linkage_name ()[0] == '#')
return;
This appears to be an old stabs hack. In the stabs removal patch
(commit eaea19f98d8) we see:
- /* '#' is a GNU C extension to allow one symbol to refer to another
- related symbol.
-
- Generally this is used so that an alias can refer to its main
- symbol. */
This is a classic example of an old style problem that gdb had:
sometimes hacks were added to the gdb core to work around problems in
symbol readers -- IMO this kind of thing should have always been
handled by the stabs reader itself, not add_symbol_to_list.
Anyway, this is obsolete now and this patch removes it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Mon, 19 Jan 2026 18:14:11 +0000 (19:14 +0100)]
[gdb/symtab] Handle zero opcode_base in line number program header
I build gdb with TSAN, and with test-case gdb.dwarf2/malformed-line-header.exp
ran into a heap-use-after-free:
...
(gdb) info line 1
==================
WARNING: ThreadSanitizer: heap-use-after-free (pid=897504)
Write of size 1 at 0x72040000d000 by main thread:
#0 dwarf_decode_line_header() gdb/dwarf2/line-header.c:356 (gdb+0xa0618c)
...
Location is heap block of size 0 at 0x72040000d000 allocated by main thread:
#0 operator new[](unsigned long) <null> (libtsan.so.2+0xa6b01)
#1 dwarf_decode_line_header() gdb/dwarf2/line-header.c:354 (gdb+0xa06159)
...
This is caused by allocating a zero-sized array (lh->opcode_base == 0), and
writing to it:
...
lh->standard_opcode_lengths.reset (new unsigned char[lh->opcode_base]);
lh->standard_opcode_lengths[0] = 1; /* This should never be used anyway. */
...
Fix this by skipping this code if lh->opcode_base == 0.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jan Beulich [Mon, 19 Jan 2026 09:42:25 +0000 (10:42 +0100)]
PPC: permit %dm0 as insn operand
When the DM registers were added, sorting of the table was broken. With
the present arrangement, this leads to (only) %dm0 not being found by the
binary search that both use sites of the table entertain.
Jan Vrany [Mon, 19 Jan 2026 08:58:41 +0000 (08:58 +0000)]
gdb/testsuite: fix FAILs in fileio.exp
I'm experiencing intermittent FAILs in fileio.exp when running on (my)
CI:
FAIL: gdb.base/fileio.exp: Open a file
FAIL: gdb.base/fileio.exp: Creating already existing file returns EEXIST
FAIL: gdb.base/fileio.exp: Open for write but no write permission returns EACCES
FAIL: gdb.base/fileio.exp: Writing to a file
...
The problem turned out to be the way the OUTDIR gets defined in fileio.c.
The path is passed down "naked" and turned into string by STRINGIFY macro.
However, if the path happens to contain name of unrelated pre-existing
C macro, this macro gets expanded during the "stringification", resulting
in (likely) different path than used in fileio.exp and therefore causing
failures.
For example, if the GDB is compiled and tested in directory
This commit fixes this by defining the OUTDIR as string literal in first
place (similarly to how it was done prior commit cc91060) and updating
quote_for_host to handle strings that themselves contains quote (").
Tested on x86_64-linux by running all tests using quote_for_host with
both target board unix and host/target board local-remote-host-native.
Alan Modra [Mon, 19 Jan 2026 04:15:26 +0000 (14:45 +1030)]
asan: coff-alpha use of uninitialised value
I think this is a false positive as the "use" is reported at a
_bfd_link_reloc_status_error call, and the value passed is not used
except when bfd_reloc_dangerous. Avoid the warning anyway.
Tom Tromey [Sun, 18 Jan 2026 02:28:13 +0000 (19:28 -0700)]
Fix multiple-successive-infcall.exp with gdbserver
PR gdb/33791 points out that my recent change to emit the thread ID in
the thread notification message broke multiple-successive-infcall.exp
when run with gdbserver. This patch fixes the oversight.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33791 Approved-By: Simon Marchi <simon.marchi@efficios.com>
Eli Zaretskii [Sun, 18 Jan 2026 09:30:06 +0000 (11:30 +0200)]
gdb/
PR gdb/33761
* gdb/ui-style.c (colorsupport) [__MINGW32__]: MS-Windows always
supports at least 8 colors, even if the "Co" capability is not in
the terminfo DB. This fixes "set style FOO foreground COLOR"
commands in the Windows native build of GDB.
Alan Modra [Sat, 17 Jan 2026 08:13:06 +0000 (18:43 +1030)]
PR 33801 strip doesn't remove .gnu.lto_.opts
OK, so people want to be able to partly destroy gcc slim LTO object
files. I don't see why not, despite HJ's policy-setting slim lto
strip -R tests. I also don't see why it matters that objcopy/strip
won't similarly break LLVM objects (pr33271).
So out goes the slim lto strip -R tests, and the strip-debug test
expecting slim lto files won't be modified in any way. strip-debug
now removes a FILE symbol, which isn't unreasonable.
PR 33801
PR 33271
PR 33246
binutils/
* objcopy.c (copy_archive, copy_file): Do not special case
gcc LTO IR files.
ld/
* testsuite/ld-plugin/lto-binutils.exp: Remove slim lto strip -R
tests.
(run_pr33246_test): Don't compare slim object files after
strip-debug.
* testsuite/ld-plugin/strip-1a-s-all.nd: Delete.
H.J. Lu [Sat, 17 Jan 2026 00:48:59 +0000 (08:48 +0800)]
gas: Update PR gas/33744 tests
Since .set directive doesn't work on alpha and hpux has a non-standard
common directive, skip the relevant tests on alpha and hpux. Also allow
2, 4, 8 byte section alignment for 1-byte section since some targets
have a minimum section alignment.
Simon Marchi [Sat, 17 Jan 2026 03:44:56 +0000 (22:44 -0500)]
gdb/i386: remove i386_dbx_reg_to_regnum
Following the removal of gdbarch_sdb_reg_to_regnum,
i386_dbx_reg_to_regnum is only used by i386_svr4_dwarf_reg_to_regnum to
handle SSE and MMX registers. Remove it and inline the relevant bits in
i386_svr4_dwarf_reg_to_regnum.
Change-Id: Id74fad6ef6798c4cd061905f1c01eadd90e0a118 Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom de Vries [Sat, 17 Jan 2026 07:44:57 +0000 (08:44 +0100)]
[gdb/tdep] Fix gdb.base/siginfo.exp on s390x-linux
On s390x-linux (SLES 15 SP5), I'm running into:
...
FAIL: gdb.base/siginfo.exp: backtrace for nexti (pattern 2)
FAIL: gdb.base/siginfo.exp: step out of handler
...
The first FAIL is caused by a failure to unwind:
...
(gdb) bt^M
#0 handler (sig=26, info=0x3ffffffe428, context=0x3ffffffe4a8) at \
gdb.base/siginfo.c:31^M
Backtrace stopped: Cannot access memory at address 0x1a00000088^M
(gdb)
...
In contrast, on x86_64-linux I get instead:
...
(gdb) bt^M
#0 handler (sig=26, info=0x7fffffffc170, context=0x7fffffffc040) at \
gdb.base/siginfo.c:31^M
#1 <signal handler called>^M
#2 0x0000000000401201 in main () at gdb.base/siginfo.c:67^M
(gdb)
...
The memory access error is triggered here in s390_sigtramp_frame_unwind_cache:
...
/* Restore the previous frame's SP. */
prev_sp = read_memory_unsigned_integer (
info->saved_regs[S390_SP_REGNUM].addr (),
word_size, byte_order);
...
while trying to read an "Old-style RT frame" (for syscall sigreturn).
The problem is that we actually have a "New-style RT frame" (for syscall
rt_sigreturn).
[ See linux kernel source file arch/s390/kernel/signal.c for a detailed
explanation of the two. ]
The choice between the two is made earlier in that same function:
...
/* New-style RT frame:
retcode + alignment (8 bytes)
siginfo (128 bytes)
ucontext (contains sigregs at offset 5 words). */
if (next_ra == next_cfa)
{
...
}
/* Old-style RT frame and all non-RT frames:
old signal mask (8 bytes)
pointer to sigregs. */
else
...
I'm not sure why the check gives the wrong result, but I noticed that
s390_sigtramp_frame_sniffer is able to distinguish between the two, so fix
this by:
- factoring out new function s390_sigtramp_p out of
s390_sigtramp_frame_sniffer, and
- using s390_sigtramp_p in s390_sigtramp_frame_unwind_cache to distinguish
between the "Old-style RT frame" and "New-style RT frame".
This fixes the backtrace.
The second failure is:
...
(gdb) step^M
32 } /* handler */^M
1: x/i $pc^M
=> 0x1000772 <handler+50>: nopr^M
(gdb) step^M
0x000003fffdffe490 in __kernel_rt_sigreturn ()^M
1: x/i $pc^M
=> 0x3fffdffe490 <__kernel_rt_sigreturn>: svc 173^M
(gdb) FAIL: gdb.base/siginfo.exp: step out of handler
...
There is some code in process_event_stop_test that is supposed to trigger:
...
if (ecs->event_thread->control.step_range_end != 1
&& (ecs->event_thread->control.step_over_calls == STEP_OVER_UNDEBUGGABLE
|| ecs->event_thread->control.step_over_calls == STEP_OVER_ALL)
&& get_frame_type (frame) == SIGTRAMP_FRAME)
{
infrun_debug_printf ("stepped into signal trampoline");
/* The inferior, while doing a "step" or "next", has ended up in
a signal trampoline (either by a signal being delivered or by
the signal handler returning). Just single-step until the
inferior leaves the trampoline (either by calling the handler
or returning). */
keep_going (ecs);
return;
}
...
but it doesn't because frame is a NORMAL_FRAME instead of a SIGTRAMP_FRAME.
This is caused by the "dwarf2" unwinder triggering, which has higher priority
than the "s390 linux sigtramp" unwinder:
...
(gdb) maint info frame-unwinders
Name Type Class Enabled
dummy DUMMY_FRAME GDB Y
dwarf2 tailcall TAILCALL_FRAME DEBUGINFO Y
inline INLINE_FRAME GDB Y
jit NORMAL_FRAME EXTENSION Y
python NORMAL_FRAME EXTENSION Y
dwarf2 NORMAL_FRAME DEBUGINFO Y
dwarf2 signal SIGTRAMP_FRAME DEBUGINFO Y
s390 linux sigtramp SIGTRAMP_FRAME ARCH Y
s390 stub NORMAL_FRAME ARCH Y
s390 prologue NORMAL_FRAME ARCH Y
...
I found some code in dwarf2_frame_sniffer:
...
/* On some targets, signal trampolines may have unwind information.
We need to recognize them so that we set the frame type
correctly. */
if (fde->cie->signal_frame
|| dwarf2_frame_signal_frame_p (get_frame_arch (this_frame),
this_frame))
return self->type () == SIGTRAMP_FRAME;
...
and an example implementation i386_linux_dwarf_signal_frame_p, and after
copying this approach, indeed the stepping failure was fixed, but the
backtrace broken again.
Instead, fix this by giving the "s390 linux sigtramp" unwinder a higher
priority:
...
(gdb) maint info frame-unwinders
Name Type Class Enabled
dummy DUMMY_FRAME GDB Y
dwarf2 tailcall TAILCALL_FRAME DEBUGINFO Y
inline INLINE_FRAME GDB Y
jit NORMAL_FRAME EXTENSION Y
python NORMAL_FRAME EXTENSION Y
s390 linux sigtramp SIGTRAMP_FRAME ARCH Y
dwarf2 NORMAL_FRAME DEBUGINFO Y
dwarf2 signal SIGTRAMP_FRAME DEBUGINFO Y
s390 stub NORMAL_FRAME ARCH Y
s390 prologue NORMAL_FRAME ARCH Y
...
Also fixes test-case gdb.base/sigaltstack.exp and gdb.base/sigbpt.exp.
Tested on s390x-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR tdep/33708
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33708
Alan Modra [Fri, 16 Jan 2026 05:49:31 +0000 (16:19 +1030)]
ld: put wild matching_sections on an obstack
so that the memory can be reclaimed easily when reset_resolved_wilds
throws it all away.
* ldlang.c (matching_obstack): New static var.
(add_matching_section): Rewrite to use matching_obstack.
(lang_init): Init matching_obstack.
(reset_resolved_wilds): Free matching_obstack.
Alan Modra [Fri, 16 Jan 2026 05:43:21 +0000 (16:13 +1030)]
Make some ldlang functions inline
These are small, and making them inline lets me call
lang_statement_append without adding a forward declaration in the
next patch.
* ldlang.c (lang_for_each_statement, lang_list_init),
(lang_statement_append): Move to..
* ldlang.h: ..here making them inline functions.
(bfd_input_just_syms): Group with other inlines.
Simon Marchi [Fri, 16 Jan 2026 18:35:57 +0000 (13:35 -0500)]
gdb/windows: replace bfd_map_over_sections with gdb_bfd_sections
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Change core_process_module_section's signature to take a cpms_data
reference instead of a void pointer.
Change-Id: Ic4f9a12c9c1479799ec87658fd88490106b61836 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 16 Jan 2026 18:35:56 +0000 (13:35 -0500)]
gdb/compile: replace bfd_map_over_sections with gdb_bfd_sections
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Rename copy_sections to copy_section and change its signature to take
explicit parameters instead of the callback-style void pointer.
Change-Id: I30f1c3c051415722f2220b7fba48103101b640e8 Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Fri, 16 Jan 2026 19:14:51 +0000 (20:14 +0100)]
[gdb] Handle AT_HWCAP3/AT_HWCAP4 in default_print_auxv_entry
On aarch64-linux, I run into:
...
(gdb) info auxv^M
...
26 AT_HWCAP2 Extension of AT_HWCAP 0x181^M
29 ??? 0x0^M
31 AT_EXECFN File name of executable 0xffffffffffb9 ...
...
28 AT_RSEQ_ALIGN rseq allocation alignment 32^M
0 AT_NULL End of vector 0x0^M
(gdb) WARNING: Unrecognized tag value: 29 ... ??? ... 0x0^M
FAIL: gdb.base/auxv.exp: info auxv on live process
...
Fix this by handling AT_HWCAP3 in default_print_auxv_entry. Likewise for
AT_HWCAP4.
Tested on aarch64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32590
Tom de Vries [Fri, 16 Jan 2026 19:14:51 +0000 (20:14 +0100)]
[include] Add AT_HWCAP3/AT_HWCAP4 in elf/common.h
Since glibc 2.39, containing commit 3ab9b88 ("powerpc: Add HWCAP3/HWCAP4 data
to TCB for Power Architecture."), glibc's elf/elf.h contains constants
AT_HWCAP3/AT_HWCAP4.
Add these in elf/common.h.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdb/testsuite: add testcase for .debug_gdb_scripts being compressed
This is a test-case to make sure that 8eb1701823e46179e3adcb49abf57126b3c49f28
("gdb: fix loading compressed scripts from `.debug_gdb_scripts`-section")
doesn't regress.
The test was mostly implemented by Tom Tromey, with the exception of the
check to make sure that the sections are actually compressed and
corrected compiler flags (-Wl,--compress-debug-sections=zlib-gabi was
missing).
This is an individual patch since the actual fix already landed in the
repository.
Simon Marchi [Fri, 9 Jan 2026 21:56:07 +0000 (16:56 -0500)]
gdb/coffread: remove debug info support
This patch removes support for reading in the COFF debug info.
I am not a specialist of the COFF format, but my understanding is that
debug info in the COFF format consisted of extra symbol table entries
describing the standard symbol table entries. For instance, when
compiling without debug info, a function would get a simple symbol
entry, akin to an ELF symbol. We would create a minimal symbol out of
that. When compiling with debug info, that symbol table entry would be
followed by special additional entries, describing things like
parameters and local variables (what would now be in DWARF). We would
create some full symbols out of that.
This patch removes everything that reads this extra information, on the
basis that any target still used today would not use it anymore, having
switched to DWARF instead. We still read the standard symbol table
entries and create minimal symbols out of that. This can be seen when
loading a Windows executable (the only COFF executable kind I know how
to produce):
I did not and can't easily test more than that. At least, the remaining
code is understandable enough that I think we would be able to fix any
bug that comes up.
This change should not alter the debugging experience on Windows.
projects / thirdparty / binutils-gdb.git / log
