Pedro Alves [Fri, 3 Oct 2025 16:45:39 +0000 (17:45 +0100)]
gdb/hip: Prepare for DWARF-assembler-based HIP testcases
Compiling a testcase with debug info (by passing passing "debug" as
gdb_compile option) has the effect of passing -g to the compiler. -g
in turn enables an LLVM option that is essential for debugging:
'-mllvm -amdgpu-spill-cfi-saved-regs'.
That option affects code generation, and some features of the DWARF
assembler machinery rely on code generated by the compiler without -g
to be the exact same as the code generated with -g.
This patch addresses that by always compiling with the LLVM option
that -g would enable.
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I64a938edf97c85d0ea9fc34b37071daa560de7e7
H.J. Lu [Thu, 2 Jul 2026 02:14:10 +0000 (10:14 +0800)]
readelf: Save and dump the original section header values
validate_section_info clears the garbage values in the section header
to avoid crash later. Save and dump the original section header values
to make the garbage values in the section header visible when dumping
section headers.
Note: orig_section_headers, instead of sane_section_headers, is added to
filedata since filedata->section_headers is used in many places. Replace
filedata->section_headers with filedata->sane_section_headers requires
a much bigger change.
* readelf.c (filedata): Add orig_section_headers.
(save_original_section_header_values): New.
(validate_section_info): Add a pointer to the original section
header and call save_original_section_header_values to save the
original section header values before clearing the section header
fields.
(get_32bit_section_headers): Allocate the original section header
buffer. Pass the original section header pointer to
validate_section_info.
(get_64bit_section_headers): Likewise.
(process_section_headers): Dump the original section header
values if they exist.
(process_relocs): Pass a dummy original section pointer to
validate_section_info.
(free_filedata): Free filedata->orig_section_headers.
* testsuite/binutils-all/corrupt-1.elf.bz2: New file.
* testsuite/binutils-all/corrupt-1.r: Likewise.
* testsuite/binutils-all/readelf.exp: Run corrupt-1.elf test.
Ronald Hecht [Mon, 15 Jun 2026 07:04:01 +0000 (09:04 +0200)]
gdb: z80: Fix endless loop in frame unwinder and validate saved register types
In z80_frame_unwind_cache, the loop scanning for the frame base pointer
(for (;; ++sp)) could run into an endless loop or scan too far if the
termination condition (sp < this_base) was not met due to corrupted
or unexpected stack layouts. This patch introduces a loop_count to
limit the scan to a maximum of 2 * addr_len iterations.
Additionally, when iterating through saved registers to adjust their
offsets into concrete addresses, the code now explicitly checks if
the register actually holds an address using is_addr() before calling
addr(). This prevents potential assertions or undefined behavior for
registers that do not contain valid address data.
gdb/ChangeLog:
* z80-tdep.c (z80_frame_unwind_cache): Limit stack scanning
to 2 * addr_len iterations to prevent endless loops. Check
is_addr() before adjusting saved register addresses.
RISC-V: Check for conflicting extensions when the linker merges arch attributes
The linker validates the arch of each input when parsing it, but never
checks the merged arch as a whole, so conflicting extensions could
silently slip through. The merge can even imply extensions that
neither input implies alone, e.g. `c' from one input and `d' from
another imply `zcd', which conflicts with `zcmp'.
After merging the input archs, add the implicit extensions to the
merged arch, then run the conflict checks on it and reject the merge
if any conflict is found. Add tests for such merges.
RISC-V: Release subset lists on all paths when the linker merges arch attributes
riscv_merge_arch_attr_info returned early on the error paths without
releasing in_subsets, out_subsets and merged_subsets, so the nodes
already added to them were leaked. The leaked nodes of in_subsets
and out_subsets also carry over into the next merge.
Route every post-parse error path through a single cleanup exit that
releases all three subset lists, and drop the now-redundant reset of
merged_subsets at entry.
gdb, amd-dbgapi-target: fix extra space in wave_coordinates
In commit 57f5450 ("gdb, amd-dbgapi-target: split
wave_coordinates::to_string"), I mistakenly left extra space in the
output of wave_coordinates' string methods. Fix this.
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Andrew Burgess [Mon, 1 Jun 2026 15:07:49 +0000 (16:07 +0100)]
gdb/python: remove frame_object::frame_id_is_next as unnecessary
Remove the frame_object::frame_id_is_next field. This has been part
of how Python handles frames since this code was first added in commit f8f6f20b6e37e6d219940fcad58b1f66124d11c1 back in 2009. The motivation
for this field can be found in a couple of comments, there's this one
on frame_id_is_next:
/* Marks that the FRAME_ID member actually holds the ID of the frame next
to this, and not this frames' ID itself. This is a hack to permit Python
frame objects which represent invalid frames (i.e., the last frame_info
in a corrupt stack). The problem arises from the fact that this code
relies on FRAME_ID to uniquely identify a frame, which is not always true
for the last "frame" in a corrupt stack (it can have a null ID, or the same
ID as the previous frame). Whenever get_prev_frame returns NULL, we
record the frame_id of the next frame and set FRAME_ID_IS_NEXT to 1. */
And this one in frame_info_to_frame_object:
/* Try to get the previous frame, to determine if this is the last frame
in a corrupt stack. If so, we need to store the frame_id of the next
frame and not of this one (which is possibly invalid). */
This field is dealing with a problem that was present in older
versions of GDB where not every stack frame had a valid frame-id, if
the stack was corrupted in some way then the last frame might have an
invalid frame-id. However, that is no longer the case. With current
GDB there is a promise that every frame has a valid frame-id. I don't
have a single commit to point to where this became the reality, but it
is my understanding of current GDB.
As an example, the frame-id of every frame (except #0) is computed as
the frame is created, any frames with a duplicate frame-id, or any
errors during computation of the frame-id, and the new frame is
discarded.
Additionally, our frame_info_ptr::reinflate mechanism relies on unique
and valid frame-ids.
The problem with the existing code is that the last frame in a
corrupted stack will hold the frame-id of the next frame, that is, the
more inner frame. This means we have two frames holding the same
frame-id, and the only difference is the frame_id_is_next flag.
However, the frapy_str function, which prints a string representation
of the frame, doesn't take frame_id_is_next into account, so printing
the last two frames in a corrupted stack, will print the same
frame-id.
We could fix this in frapy_str and also frapy_repr by checking the
frame_id_is_next flag and then fetching the previous frame-id, but
this would still assume that the previous frame has a valid-id, so we
might as well just drop the frame_id_is_next flag and make everything
simpler.
There's a new test which exposes the incorrectly printed frame-id
problem.
While testing I needed to "fix" the results for two existing tests.
In frame_info_to_frame_object, in order to figure out if we should use
the next frame, we called get_prev_frame. This would cause GDB to
always unwind 1 extra level of the stack.
What this means is that, if there is an error, or some diagnostic
output, when unwinding frame #1, then this will show up when trying to
access frame #0 via the Python API as frame_info_to_frame_object on
frame #0 would call get_prev_frame, which would then unwind frame #1.
After this commit this is no longer the case. We only see
output (either errors, or diagnostic output) associated with frame #1
when we actually try to unwind to frame #1. The two tests that needed
updating were expecting output associated with frame #1 while printing
frame #0. This is now fixed and the output for frame #1 occurs later
on. I think this is an improvement.
Andrew Burgess [Mon, 1 Jun 2026 10:32:53 +0000 (11:32 +0100)]
gdb/testsuite: don't overwrite test executable in py-frame.exp
In gdb.python/py-frame.exp when we re-compile the test executable
without debug information, give it a new, unique, name to make
re-running the tests outside the testsuite easier.
While I was in the area I removed a `gdb_exit` call that was not
necessary, `prepare_for_testing` calls `clean_restart` which already
does a `gdb_exit`.
There should be no change in what is being tested after this commit.
Keith Seitz [Tue, 7 Jul 2026 19:10:08 +0000 (12:10 -0700)]
[gdbserver] Use const_target_desc_up for regformat tdescs
Regformat tdescs are now declared 'const_target_desc_up' by
gdb's regdat.sh, so update the various gdbserver target descriptions
to observe this API change.
There should be no user visible changes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Keith Seitz [Tue, 7 Jul 2026 19:10:08 +0000 (12:10 -0700)]
regdat.sh: generate const_target_desc_up for register descriptions
Late last year, a patch propagated the use of target_desc unique
pointers (commit 1a5362ce51ef79ffb61caa20c93284dc368dc74a). At the
time, the "old regformats/regdat.sh [weren't] changed because their
target_desc objects are statically allocated in the generated files."
Unfortunately that re-introduced ODR violations on ppc64le:
CXXLD gdbserver
../../src/gdbserver/../gdb/arch/ppc-linux-tdesc.h:46:29: error: ‘tdesc_powerpc_isa207_htm_vsx64l’ violates the C++ One Definition Rule [-Werror=odr]
46 | extern const_target_desc_up tdesc_powerpc_isa207_htm_vsx64l;
| ^
powerpc-isa207-htm-vsx64l-generated.cc:26:27: note: ‘tdesc_powerpc_isa207_htm_vsx64l’ was previously declared here
26 | const struct target_desc *tdesc_powerpc_isa207_htm_vsx64l;
| ^
powerpc-isa207-htm-vsx64l-generated.cc:26:27: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
Update regdat.sh so that generated init_registers_* code matches the
const-unique_ptr-based target description API, resolving the ODR violation.
A follow-up patch updates various gdbserver architectures to
accommodate this API change.
Tested on ppc64le and s390x Fedora 43 and mips-linux
cross build (all with LTO).
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28444
Simon Marchi [Mon, 6 Jul 2026 16:40:09 +0000 (12:40 -0400)]
gdb/record-full: make record_full_arch_list_add take an rvalue ref
record_full_arch_list_add moves its `rec` argument, so it should take an
rvalue ref to reflect that. Otherwise the fact that the object is moved
from can be a "surprise" to the callers.
Alan Modra [Tue, 7 Jul 2026 08:10:28 +0000 (17:40 +0930)]
Check the result of two bfd_alloc calls in elf.c
PR 34131
* elf.c: Remove unnecessary casts on bfd_[zm]*alloc return value.
Do without "amt" temp var in a few cases.
(assign_section_numbers): Check for NULL return from bfd_zalloc.
(elfobj_grok_stapsdt_note_1): Likewise for bfd_alloc.
Alan Modra [Tue, 7 Jul 2026 01:32:00 +0000 (11:02 +0930)]
Re: LoongArch: Fix relaxation alignment with ld -r (PR 33236)
Correct sh_size and sh_entsize to use external reloc size.
loongarch32-elf +FAIL: Linkonce sections with assembler generated notes
loongarch32-elf +FAIL: ld-loongarch-elf/relax-align-ld-r
Alan Modra [Tue, 7 Jul 2026 00:38:18 +0000 (10:08 +0930)]
alpha, rl78, rx: UB in reloc handling
This patch avoids undefined behaviour and divide by zero exceptions in
some relocation processing. In most cases, unsigned arithmetic is
used which has defined overflow characteristics. Arithmetic right
shift, division, and modulo operations have more special cases. See
the explanation in commit 30200464e9dd.
objcopy --update-section specifying a SHT_GROUP section hits a case
where output_section is NULL.
* objcopy.c (copy_object): Don't segfault when update_sections
output_section is NULL. Remove the "not found" part of
existing error so this message can be used.
* testsuite/binutils-all/update-section.exp: Update to suit.
Pedro Alves [Wed, 24 Jun 2026 13:45:56 +0000 (14:45 +0100)]
Windows/rocm-solib: Don't hardcode namespaces support
rocm_solib_ops currently unconditionally returns true to
solib_ops::supports_namespaces. That works OK on Linux where the
underlying solib ops is svr4. But on Windows, the underlying solib
ops is solib-target, which does not support namespaces. The result
is:
(gdb) info shared
/home/pedro/rocm/gdb/build/gdb/solib.h:270: internal-error: num_active_namespaces: namespaces not supported
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
Thread 1 hit Breakpoint 1, internal_verror (file=0x7ff71a27fc80 <SCRIPTING_SEARCH_FLAG+52> "/home/pedro/rocm/gdb/build/gdb/solib.h", line=270,
fmt=0x7ff71a27fc5e <SCRIPTING_SEARCH_FLAG+18> "%s: namespaces not supported", ap=0xfff1a8 "\270\374'", <incomplete sequence \367\177>)
at /home/pedro/rocm/gdb/build/gdb/utils.c:514
514 internal_vproblem (&internal_error_problem, file, line, fmt, ap);
(gdb) bt
#0 internal_verror (file=0x7ff71a27fc80 <SCRIPTING_SEARCH_FLAG+52> "/home/pedro/rocm/gdb/build/gdb/solib.h", line=270,
fmt=0x7ff71a27fc5e <SCRIPTING_SEARCH_FLAG+18> "%s: namespaces not supported", ap=0xfff1a8 "\270\374'", <incomplete sequence \367\177>)
at /home/pedro/rocm/gdb/build/gdb/utils.c:514
#1 0x00007ff719c75cf4 in internal_error_loc (file=0x7ff71a27fc80 <SCRIPTING_SEARCH_FLAG+52> "/home/pedro/rocm/gdb/build/gdb/solib.h", line=270,
fmt=0x7ff71a27fc5e <SCRIPTING_SEARCH_FLAG+18> "%s: namespaces not supported") at /home/pedro/rocm/gdb/build/gdbsupport/errors.cc:57
#2 0x00007ff719f0aafe in solib_ops::num_active_namespaces (this=0xbb3a0b0) at /home/pedro/rocm/gdb/build/gdb/solib.h:270
#3 0x00007ff719eca99e in rocm_solib_ops::num_active_namespaces (this=0xc9388a0) at /home/pedro/rocm/gdb/build/gdb/solib-rocm.c:211
#4 0x00007ff719a14d33 in print_solib_list_table (solib_list=..., print_namespace=true) at /home/pedro/rocm/gdb/build/gdb/solib.c:1011
#5 0x00007ff719a15833 in info_sharedlibrary_command (pattern=0x0, from_tty=1) at /home/pedro/rocm/gdb/build/gdb/solib.c:1115
rocm_solib_ops will stop sitting on top of another solib
implementation once the multi solib provider work lands, but
meanwhile, it'd be helpful to not crash.
Fix this by making rocm_solib_ops::supports_namespaces() delegate to
the underlying host solib ops like other methods do.
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I1627c6e2f1b1c171c013c8457e9bfca92d5f4dc5
Pedro Alves [Tue, 5 Aug 2025 22:47:24 +0000 (23:47 +0100)]
gdb.rocm: Don't include unistd.h when not necessary
gdb.rocm/code-object-load-while-breakpoint-hit.cpp is including
unistd.h unnecessarily AFAICS. Don't include it, so this test can
compile on Windows (x86_64-pc-windows-msvc) as well.
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I9f469fd4b061ab9895c8bbbd408939e4df2a4e92
Pedro Alves [Fri, 12 Dec 2025 12:12:30 +0000 (12:12 +0000)]
Windows: Normalize backslashes to forward slashes
Currently, on native Windows, GDB presents a mix of backslashes and
forward slashes to users, like e.g.:
...
attach 15044
Attaching to program: C:\msys2\home\alves\gdb\build-testsuite\outputs\gdb.base\attach\attach.exe, process 15044
...
[Switching to thread 1 (Thread 15044.0x1294)]
main () at C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c:19
19 while (! should_exit)
(gdb) FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach
...
Note how above, the "attach" command uses backslashes, and the source
path uses forward slashes.
Most annoyingly, depending on compiler, you can end up with mixed
slash styles in the same path:
Temporary breakpoint 1 at 0x1400010ec: file C:/rocgdb/src/gdb/testsuite/gdb.rocm\simple.cpp, line 33.
^
A while ago, in commit a63213cd37 ("MSYS2+MinGW testing: Unix <->
Windows path conversion"), I had made the testsuite normalize
backslashes to forward slashes, among other things. I had said in the
commit log there:
"It's arguable whether GDB itself should do this sanitization. I
suspect it should. I personally dislike seeing backward slashes in
e.g., "info shared" output, or worse, mixed backward and forward
slashes. Still, I propose starting with a testsuite adjustment that
moves us forward, and handle that separately. I won't be surprised if
we need the new routine for some cases even if we adjust GDB."
After running into some other tests that would need backslash
adjustment, and also because this is something user-visible, not just
a testsuite issue, I decided to bite the bullet and make GDB itself do
the slashes normalization.
This patch fixes all the cases of backslashes that I could find:
- source files and compilation directory
- executable name, and shared library names
- cd/pwd commands
It does this by normalizing slashes at some strategic places. The
conversion is only attempted if needed -- i.e., if debugging on
Windows, or cross-debugging Windows programs from a non-Windows host.
For executable/shared library names, this is doing the backslash ->
forward slash conversion completely on the host side in common code,
without touching the target backend files in either GDB or GDBserver,
by design, so that this is all completely a client side decision, and
works the same against any Windows GDBserver version, against remote
servers other than ours (e.g., Wine's), so we can change it later if
we want, etc.
I did tweak the gdb and gdbserver backends for the other way around
(forward slash => backslash), to make sure that they pass backslashes
to CreateProcess, so that inferiors see native backslashes in their
own argv[0]. For GDBserver, it would already have been possible to
launch an executable with forward slashes before (e.g., when debugging
from a Linux or Cygwin client), so this makes Windows gdbserver
behavior more consistent, independently of client, too.
I did not add an option to make this configurable at runtime on
purpose. I don't see the point, it'd just add more complication and
testing surface. Always normalizing keeps it simple.
For the source paths, I considered doing the normalization earlier in
the DWARF reader, but decided against it, because that would force
extra copying of strings -- the DWARF reader works mostly by passing
around const char pointers. Also, the places I picked in principle
will automatically handle PDB if/when we get to it.
The buildsym.c change takes care of compilation directory paths.
The allocate_symtab change takes care of source paths. That one
required a (temporary) copy, but I think that that's acceptable there.
The gdb_realpath change is needed because just before the touched code
there's a GetFullPathName call, which itself normalizes to
backslashes.
The exec.c and solib.c changes take care of executable and shared
libraries.
The change to testsuite/lib/gdb.exp, to adjust to forward-slash style
for DOS full names, are necessary otherwise MI tests break. E.g.:
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x00007ff780461508",
func="main",args=[],file="C:/rocgdb/src/gdb/testsuite/gdb.mi/basics.c",
fullname="C:/rocgdb/src/gdb/testsuite/gdb.mi/basics.c",line="64",arch="i386:x86-64"},
thread-id="1",stopped-threads="all"
FAIL: gdb.mi/gdb2549.exp: mi runto main (unknown output after running)
gdb.base/set-cwd.exp was the only test I found (so far at least) that
required adjustment, but note that without this patch that testcase
fails and throws TCL errors, like:
...
FAIL: gdb.base/set-cwd.exp: test_cwd_reset: inferior cwd is correctly set
ERROR: couldn't compile regular expression pattern: invalid escape \ sequence
...
It passes cleanly with the patch.
Below's the before / after comparison of different commands / output.
Before:
Reading symbols from ./outputs/gdb.rocm/simple/simple...
(gdb)
start
Temporary breakpoint 1 at 0x1400010ec: file C:/rocgdb/src/gdb/testsuite/gdb.rocm\simple.cpp, line 33.
Starting program: C:\msys2\home\alves\gdb\build-testsuite\outputs\gdb.rocm\simple\simple
Thread 1 hit Temporary breakpoint 1, main () at C:/rocgdb/src/gdb/testsuite/gdb.rocm\simple.cpp:33
33 hipError_t error = hipMalloc (&result_ptr, sizeof (int));
Thread 1 hit Temporary breakpoint 1, main () at C:/rocgdb/src/gdb/testsuite/gdb.rocm\simple.cpp:33
33 hipError_t error = hipMalloc (&result_ptr, sizeof (int));
(gdb)
(gdb) info inferiors
Num Description Connection Executable
* 1 process 15620 1 (native) C:\msys2\home\alves\gdb\build-testsuite\outputs\gdb.rocm\simple\simple
(gdb) info source
Current source file is C:/rocgdb/src/gdb/testsuite/gdb.rocm\simple.cpp
Compilation directory is C:\msys2\home\alves\gdb\build-testsuite
Located in C:\rocgdb\src\gdb\testsuite\gdb.rocm\simple.cpp
(gdb) info sources
C:\msys2\home\alves\gdb\build-testsuite\outputs\gdb.rocm\simple\simple:
(gdb) info inferiors
Num Description Connection Executable
* 1 process 19920 1 (native) C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.rocm/simple/simple
The s390 32-bit target (s390-*) is deprecated and planned for removal
in a future release, along with the elf32-s390 target format. Emit an
error for this target during configure, which can be overridden using
option --enable-obsolete.
Linux Kernel 6.19 removed s390 32-bit compatibility support. [1]
Glibc 2.43 [2] and GCC 16.1 (compiler option -m31) [3] deprecated
s390 32-bit with the intent to remove it in a future release.
The s390 64-bit target (s390x-*) remains supported.
IBM z13 introduced the "store CPU counter multiple" (stcctm) instruction
with the Store-CPU-Counter-Multiple Facility, which is part of the
CPU-Measurement Facilities (CPUMF) [1].
While at it add a comment to the s390 opcode table for the existing
CPUMF instructions.
[1]: The Load-Program-Parameter and the CPU-Measurement Facilities,
SA23-2260-08,
https://www.ibm.com/docs/en/module_1678991624569/pdf/SA23-2260-08.pdf
opcodes/
* s390-opc.txt (stcctm): Add store CPU counter multiple
instruction. Add comment on CPUMF instructions.
gas/testsuite/
* gas/s390/zarch-z13.d (stcctm): Add test for store CPU counter
multiple instruction.
* gas/s390/zarch-z13.s (stcctm): Likewise.
aarch64: Fix assembler internal error for %dtprel relocations
The current implementation creates the DTPREL fixup before reserving
the storage for the corresponding ".xword". GCC's "%dtprel" support
for TLS DWARF debug information exposed this during an AArch64 bootstrap,
where the libsanitizer/tsan DWARF layout places the DTPREL fixup at a
frag boundary. Reserving the storage before creating the fixup avoids
this corner case.
gas/
PR binutils/34357
* config/tc-aarch64.c (s_aarch64_cons) : Fix the storage order for
DTPREL.
This is a refactoring to allow reusing pieces and also to let the code
document itself better. Currently the reuse opportunity exists in the
downstream debugger.
Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
The group id coordinates and the wave number in workgroup that are
being formatted to a string in wave_coordinates::to_string are
uint32_t. Use pulongest to print them.
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
mengqinggang [Fri, 22 May 2026 01:38:49 +0000 (09:38 +0800)]
LoongArch: Fix relaxation alignment with ld -r (PR 33236)
LoongArch has the same issue as RISC-V for PR 33236 [1].
Section alignment can't be adjusted for objects generated by ld -r.
If previous sections are relaxed, the subsequent section maybe misaligned.
To fix this, add an align section and an align relocation before each
section when ld -r. And change the section alignment to 4 to disable
the default section start address calculation.
ld.lld has fixed this issue in the following two patches [2] [3].
mengqinggang [Tue, 16 Jun 2026 11:10:26 +0000 (19:10 +0800)]
LoongArch: Fix linker relaxation alignment
When linking multiple objects, relaxation can cause alignment issues.
Input section's output_offset is updated in relaxation without considering
alignment. Update section output_offset by align_opwer.
Fangrui Song [Sun, 8 Feb 2026 19:56:49 +0000 (11:56 -0800)]
gas: add --reloc-section-sym={all,internal,none} option for ELF
When generating relocations for non-ifunc local symbols that satisfies
several conditions, GAS converts them to reference the section symbol
(STT_SECTION) instead, folding the original symbol's offset into the
addend. This allows the original local symbol to be omitted from
.symtab, but the STT_SECTION symbol itself must be present, so the
conversion saves .symtab entries only when a section has more than one
local symbol referenced by relocations.
Add --reloc-section-sym to control this conversion:
- all (default): convert all eligible local symbols
- internal: only convert compiler-generated locals (.L prefix)
- none: never convert; keep all symbols as-is in relocations
This is useful for debugging and for tools that benefit from preserved
symbol names.
Alan Modra [Sat, 4 Jul 2026 10:27:43 +0000 (19:57 +0930)]
pr34322: assertion failure in get_or_create_member_type
I thought about warning "DW_TAG_member without struct/union parent"
here but decided that doesn't help much as the warning is disconnected
from output. As it is the --map-global-vars code silently ignores
unexpected attributes that might be found in fuzzed files. I'm fine
with that too.
PR 34322
* dwarf.c (get_or_create_member_type): Return NULL on NULL parent.
(insert_element_in_list): Ignore DW_TAG_member without struct
or union parent.
gdb/record: Add support for recording BMI1 instructions
This commit adds support for recording all instructions of the Bit
Manipulation Instruction set 1, for x86 cpus. The specific instructions
are:
* andn
* bls[i|r|msk]
* bextr
* [l|t]zcnt
Also add them to the avx test. While BMI is a different set of
instructions, there are no currently existing CPUs that have access to
AVX2 and don't have access to BMI1 and BMI2, so it seems like a
reasonable idea to keep them together, as the avx test already requires
AVX2.
H.J. Lu [Wed, 1 Jul 2026 02:15:30 +0000 (10:15 +0800)]
readelf: Update dynamic tag processing and validate section info
Count DT_RELR relocations using dynamic tags when section header isn't
used. Ignore section sh_offset and sh_size if they are larger than file
size.
One side effect is that we now display
readelf: Warning: Ignore the out of range sh_offset value of 2199023261148 for section 17
readelf: Warning: Ignore the out of range sh_size value of 13 for section 17 with sh_offset value of 2199023261148
...
[17] .fini PROGBITS 00000000000015dc 000000 000000 00 AX 0 0 4
...
PR binutils/34326
PR binutils/34339
* readelf.c (update_all_relocations): Skip if nentries == 0.
(validate_section_info): New.
(get_32bit_section_headers): Call validate_section_info.
(get_64bit_section_headers): Likewise.
(process_relocs): Call count_relr_relocations for relocations
from dynamic tags. Skip if values in DT_RELENT/DT_RELAENT
are larger than values in DT_RELSZ/DT_RELASZ.
(process_got_section_contents): Skip if all_relocations_count
== 0.
ld/
PR binutils/34339
* testsuite/ld-x86-64/binutils.exp: Run PR binutils/34339 tests.
* testsuite/ld-x86-64/got-2.s: New file.
* testsuite/ld-x86-64/libgot-2.rd: Likewise.
Guinevere Larsen [Fri, 15 May 2026 14:57:04 +0000 (11:57 -0300)]
gdb/record: rename record_full_list to record_full_log
Now that we no longer use a linked list to manage the history, the name
"record_full_list" is no longer meaningful. This commit changes the name
to record_full_log since it is the execution log. I decided to not say
"record_full_execution_log" to avoid overly long lines when accessing
it.
gdb/record: Define new version of the record-save section
With the changes to the internal representation of the history, we can
no longer support the previous record save format. This commit makes it
official, documenting the new format and changing the magic number.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Guinevere Larsen <guinevere@redhat.com>
gdb/record: extract the PC to record_full_instruction
This commit makes it so the PC is not saved as part of the
record_full_instruction effects, but rather gets a special location.
That is because a couple of commands would really benefit from it being
easy to find the PC (especially ones from record-btrace that's haven't
been implemented to record-full yet, such as the ones in PR
record/18059), while also possibly allowing for one fewer resizing of
the effect vector (and saving an entire byte in the process).
This commit also refactored record_full_read_entry_from_bfd and
record_full_write_entry_to_bfd, to make them methods of
record_full_reg_entry and record_full_mem_entry, and also creates
similar methods for record_full_entry and record_full_instruction.
These could be turned into constructors in a future step of
c++ification, but it felt like too much change for a single commit.
gdb/record: c++ify internal structures of record-full.c
This commit adds a constructor, destructor, and some methods to the
structures record_full_entry, record_full_reg_entry and
record_full_mem_entry. This is a move to disentangle the internal
representation of the data and how record-full manipulates it for
replaying.
Along with this change, record_full_entry is changed to use an
std::variant, since it was basically doing that already, but now we have
the stdlibc++ error checking to make sure we're only accessing elements
we're allowed to.
Guinevere Larsen [Fri, 29 May 2026 16:42:40 +0000 (13:42 -0300)]
gdb/record: factor out reading and writing the execution log to corefile
Before this commit, the functions to read and write the execution log to
a corefile would would have a large section dedicated to handling a
single entry from the log. This commit factors out those large sections
into their own functions, record_full_read_entry_from_bfd and
record_full_write_entry_to_bfd, respectively.
There should be no functional changes after this commit.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com> Approved-By: Guinevere Larsen <guinevere@redhat.com>
Guinevere Larsen [Thu, 28 May 2026 18:36:33 +0000 (15:36 -0300)]
gdb/record: Refactor record history
This is the first step in a large refactor in how GDB keeps execution
history. Rather than using a linked list where multiple entries can
describe a single instruction, the history will now be stored in an
std::deque, each instruction being one entry in the deque.
The choice was initially to use an std::vector, but it would become
unwieldy because it needs all the memory to be consecutive, which is
hard for 200 thousand entries. Deque was picked because it was a nice
midpoint between vector (maximum cache cohesion) and linked list
(maximum ease of finding space to store more).
Each instruction in memory will be now one record_full_instruction
entry, which for this commit just contains a vector of
record_full_entry for the effects of the instruction, and the data that
was stored in the record_full_end entry (that is, the instruction number
and the signal, if any).
This change introduced a minimal performance improvement (what's
important is that it isn't a degradation) and a reduction in the total
memory footprint of roughly 20% if the entire history is used.
gdb, amd-dbgapi-target: use pulongest to print id handles
In amd-dbgapi-target, there are a number of cases where identifier
handles that are obtained from dbgapi are being printed. Those
handles are defined to have type uint64_t. Use pulongest when
printing them for improved portability.
In one case, `ptid.tid ()` was being printed for the wave id. Change
this to use `wave_id.handle` for consistency with the other cases.
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Lancelot SIX [Wed, 1 Jul 2026 16:09:25 +0000 (17:09 +0100)]
gdb/testsuite: fix gdb.rocm/interrupt-twice
Since 246aecb1cd1 "gdb/testsuite: make gdb_breakpoint, runto and
runto_main use parse_args", gdb_breakpoint arguments changed. The
gdb.rocm/interrupt-twice.exp testcase was not updated to call
gdb_breakpoint with correct arguments. This due to the new test being
reviewed before the gdb_breakpoint landed, but it being pushed after.
This patch fixes this issue.
Change-Id: I0204e2c3cc9b704c79ce01386134e13b018593b8 Reviewed-By: Tankut Baris Aktemur <TankutBaris.Aktemur@amd.com>
Luis Machado [Wed, 1 Jul 2026 19:01:56 +0000 (14:01 -0500)]
gdb: replace alloca with gdb::unique_xmalloc_ptr in remote-fileio.c
remote_fileio_extract_ptr_w_len parsed a debuggee controlled 64 bit
length, narrowed it to int with no bounds check, and the value flowed
directly into alloca() across RSP File I/O handlers (Fopen, Frename,
Funlink, Fstat, Fsystem). A malicious inferior or remote stub could
send a crafted packet with a large path length, displacing the stack
pointer by up to 2 GiB and potentially crashing the debugger.
remote_fileio_extract_ptr_w_len now rejects negative lengths, lengths
that would overflow the int result (greater than INT_MAX), and zero.
An allow_zero_length flag lets the Fsystem handler opt in to the zero
length sentinel that signals a NULL cmdline query. All other handlers
use the default and are protected without any per call checks. Oversized
names are rejected naturally by the underlying syscall with ENAMETOOLONG.
All alloca(length) calls have been replaced with
gdb::unique_xmalloc_ptr<char>, so an oversized but positive length now
fails as a graceful heap allocation error rather than corrupting the
stack.
Add a selftest that exercises various problematic cases.
Signed-off-by: Luis Machado <luis.machado@amd.com> Approved-By: Pedro Alves <pedro@palves.net>
Luis Machado [Mon, 29 Jun 2026 13:56:13 +0000 (08:56 -0500)]
gdb/testsuite: deduplicate --offload-arch targets in hcc_amdgpu_targets
On systems with multiple identical GPUs, find_amdgpu_devices returns one
entry per device, causing hcc_amdgpu_targets to emit redundant
--offload-arch flags when compiling HIP test programs (e.g. eight
--offload-arch=gfx942 flags on an 8-GPU MI300 system).
Deduplicate the target list in hcc_amdgpu_targets, preserving order, so
each unique architecture appears exactly once regardless of how many
physical devices share it. The same deduplication is applied when the
list comes from the HCC_AMDGPU_TARGET environment variable. An array
is used for the seen-set to give O(1) membership tests.
Add gdb.rocm/hcc-amdgpu-targets.exp to unit-test the deduplication
logic across both the env-var and device-enumeration code paths, without
requiring a GPU.
Jon Turney [Fri, 19 Jun 2026 12:47:03 +0000 (13:47 +0100)]
objdump: Fix private header ('-p') import table output for pe-aarch64
The private header ('-p') import table output for pe-aarch64 (and
probably all other 64-bit arches apart from x86_64) is truncated after the
first import.
The distinction between the conditional branches here should be between
PE32 (32-bit) and PE32+ (somewhat confusingly, the 64-bit version of the
PE format).
PE file format specification [1] states under "Import Lookup Table":
"An import lookup table is an array of 32-bit numbers for PE32 or an
array of 64-bit numbers for PE32+."
Tom Tromey [Thu, 2 Jul 2026 12:51:36 +0000 (06:51 -0600)]
Fix ptid_t selftest crash
Sam James pointed out that my recent patch to add ptid_t::parse caused
a selftest crash.
At first I couldn't see why this did not crash for me, but then I
realized that ptid_t::parse didn't unconditionally initialize '*obuf'.
Initializing it to nullptr made this crash reliably.
The underlying bug is that some code paths in ptid_t::parse don't set
obuf on return. This patch fixes the bug by passing 'obuf' down to
hex_or_minus_one.
Since this is straightforward and fixes a new crash, I'm checking it
in.
Richard Earnshaw [Mon, 29 Jun 2026 15:46:27 +0000 (16:46 +0100)]
aarch64: Remove +mpamv2 feature option
The remaining mpamv2 details only use system registers; so by our
conventions we do not use a feature option to enable them. Remove the
now redundant +mpamv2 architecture option and adjust the tests
accordingly.
Clément Chigot [Fri, 20 Feb 2026 14:43:03 +0000 (15:43 +0100)]
ld/testsuite: add support for remote testing in ld-cdtest
This converts the existing to code to use "remote_load" allowing
execution on both native and remote targets.
The "diff" between the output and the expected result has been
transformed to the usual regexp_diff. The previous could have been
transformed into `remote_exec build diff` but tends to be fickled with
new lines.
Alan Modra [Thu, 2 Jul 2026 01:34:13 +0000 (11:04 +0930)]
PR 34327 More out of bounds accesses in reloc special functions
I don't claim to have caught all places where reloc special functions
don't sanity check input, but this should be most of them. Hopefully
this does not expose odd reloc howto entries like the mmix one in the
previous patch.
Alan Modra [Thu, 2 Jul 2026 01:18:34 +0000 (10:48 +0930)]
PR 34327 Out of bounds accesses in reloc special functions.
As per the PR, s12z lacked any reloc offset sanity checking, the
others all just checked that the offset started within the section
rather than checking the field was contained in the section.
Using the proper check for mmix exposed a problem in the howto table,
present since the initial mmix commit. The R_MMIX_BASE_PLUS_OFFSET
field is actually two bytes, located at the reloc address. Making it
an eight byte field is just wrong, as doing that indicates the field
is at the reloc address plus six bytes for a big-endian target.
Presumably this was done for overlow reporting, which is properly done
by appropriately setting complain_on_overflow.
Haochen Jiang [Tue, 30 Jun 2026 07:58:35 +0000 (15:58 +0800)]
x86: Disable AMX-TF32 by default
AMX-TF32 got depublished in ISE062. Just like AMX-TRANSPOSE, we
will keep the AMX-TF32 support for now in case there are x86 vendors
want to utilize the feature. AMX-TF32 will not show up on any
Intel/AMD hardware. Also in foreseeable future, no hardware will
support AMX-TF32, we will disable it by default. For testcases,
we will simply add .arch .amx_tf32 to keep the original test
intuition.
H.J. Lu [Wed, 1 Jul 2026 23:02:48 +0000 (07:02 +0800)]
readelf: Avoid may be used uninitialized warning from GCC 14
GCC 14 fails to recognize that rel_entsz and entsz_name are unused when
process_relocs returns early for error:
.../binutils/readelf.c:10127:18: error: ‘rel_entsz’ may be used uninitialized [-Werror=maybe-uninitialized]
10127 | if (rel_entsz == 0)
| ^
...
.../binutils/readelf.c:10129:19: error: ‘entsz_name’ may be used uninitialized [-Werror=maybe-uninitialized]
10129 | printf (_("<missing or corrupt dynamic tag: %s>\n"),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10130 | entsz_name);
Clear them before returning error. Also replace reltype_unknown with
default since GCC 14 fails to see that reltype_unknown is the only
unhandled value for relocation_type enum.
PR binutils/34324
* readelf.c (process_relocs): Clear rel_entsz and entsz_name
before returning error on missing DT_REL and DT_RELA dynamic
tags.
Tom Tromey [Wed, 11 Mar 2026 20:17:50 +0000 (14:17 -0600)]
Do not write negative PID or TID in remote protocol
Currently both gdb and gdbserver can write a negative number for the
PID or TID. However, the only negative value that really makes sense
is the special case of "-1" -- in other cases if the PID or TID has
the high bit set, it should still be written as a positive number.
This patch attempts to fix the bug.
v2 of this patch combines the implementations and moves them to
gdbsupport. I tried making these standalone functions in rsp-low.cc,
but that runs afoul of libipa. So, I made them methods of ptid_t.
The new unit tests pointed out that round-tripping a sign-extended
number didn't really work, because the checks were done via ULONGEST.
It's kind of unfortunate that the PID and LWP are host-dependent
types. This should probably be fixed, but I haven't done so here.
Meanwhile I changed the checks to use the corresponding unsigned type.
Peter Damianov [Tue, 23 Jun 2026 21:38:07 +0000 (17:38 -0400)]
ld/testsuite: Add comprehensive PE COFF weak external tests
Add tests covering the full matrix of weak/strong symbol interactions
for PE COFF weak externals, based on testcases by Martin Storsjo.
The archive test covers PE weak externals whose public name is backed
by a real fallback definition, and ensures weak declarations with the
null fallback are not advertised as archive providers.
ld/testsuite/
* ld-pe/pe-compile.exp (weak_ext_test): New proc. Compiles
source files, links via gcc, and runs natively if possible.
(weak_ext_archive_test): New proc.
Add tests: normal, weak-undef, weak-defined,
weak-decl-weak-def, strong-undef-weak-def-archive, weak-use,
weak-override, weak-duplicate, weak-def-override, weak-def-use.
* ld-pe/weak-ext-main.c: New file.
* ld-pe/weak-ext-main-weak.c: New file.
* ld-pe/weak-ext-main-weak-def.c: New file.
* ld-pe/weak-ext-add2.c: New file.
* ld-pe/weak-ext-add1-weak-chained.c: New file.
* ld-pe/weak-ext-dummy.c: New file.
* ld-pe/weak-ext-expected1.c: New file.
* ld-pe/weak-ext-expected3.c: New file.
* ld-pe/weak-ext-expected5.c: New file.
* ld-pe/weak-ext-expected3-add1-weak.c: New file.
Peter Damianov [Tue, 23 Jun 2026 21:38:06 +0000 (17:38 -0400)]
bfd: Handle PE weak externals with real fallbacks in archives
PE weak externals are canonicalized as undefined BFD symbols, even
when their auxiliary entry names a real fallback definition in the same
object. Archive map generation therefore skipped the public weak name,
so a strong undefined reference to that name could not extract the
archive member.
Include such PE weak externals in the archive map, but only when the
fallback is a real definition rather than the absolute-zero null symbol
used for weak declarations with no fallback. Also avoid extracting an
archive member again during repeated archive searches once the weak
external resolves through a defined fallback.
Fixes: https://gcc.gnu.org/PR124263
bfd/
* archive.c: Include coff-bfd.h.
(_bfd_compute_and_push_armap): Include PE weak externals in
the archive map when their fallback is a real definition.
* coff-bfd.c (bfd_coff_pe_weak_external_has_real_fallback): New
function.
* coff-bfd.h (bfd_coff_pe_weak_external_has_real_fallback):
Declare.
* cofflink.c (coff_link_hash_pe_weak_external_has_real_fallback):
New function.
(coff_link_check_archive_element): Avoid extracting an archive
member again for a PE weak external whose real fallback is
already defined.
Peter Damianov [Tue, 23 Jun 2026 21:38:05 +0000 (17:38 -0400)]
PE-COFF: Prefer weak external with defined fallback over null fallback
When two PE COFF weak externals for the same symbol are linked (both
C_NT_WEAK with aux records), the generic linker takes no action on the
second one (NOACT: weak undef meets existing weak undef). This means
the first file's fallback alias always wins regardless of whether it
points to a real definition or to NULL.
This causes a problem when a weak declaration (fallback = NULL,
i.e. "resolve to NULL if nothing provides it") is linked before a
weak definition (fallback = actual function body). The symbol resolves
to address 0 at runtime, causing a crash when called.
Fix this by comparing the fallback targets when two weak externals
meet: if the incoming weak external's fallback resolves to a defined
symbol and the existing one does not (or points to NULL),
update the aux record to use the better fallback.
Peter Damianov [Tue, 23 Jun 2026 21:38:04 +0000 (17:38 -0400)]
PE-COFF: Fix weak external symbol resolution when strong undef is seen first
When linking PE-COFF objects, a weak external symbol (C_NT_WEAK with an
aux record specifying a fallback alias) may fail to resolve if a strong
undefined reference to the same symbol is encountered before the weak
definition. This causes "undefined reference" errors for symbols like
operator new or personality routines that GCC emits as weak externals
with a fallback to a default implementation.
There are two problems:
1. In coff_link_add_symbols, when the generic linker resolves a weak
undefined against an existing strong undefined (NOACT in the action
table), the COFF-specific symbol_class and aux record were not stored
because the existing hash entry already had non-null class/type from
the first (strong) object file.
2. In _bfd_coff_generic_relocate_section, the weak alias fallback only
triggered for bfd_link_hash_undefweak symbols. When a strong undef
is seen first, the hash type stays bfd_link_hash_undefined (the
generic linker does not downgrade it), so the fallback was skipped.
Fix by extending the condition in coff_link_add_symbols to also update
symbol_class and aux when the incoming symbol is a PE weak external
with aux and the existing hash is still undefined. Also extend the
relocation handler to resolve the weak alias fallback for
bfd_link_hash_undefined symbols that carry C_NT_WEAK class and have
an aux record.
bfd/
* cofflink.c (coff_link_add_symbols): Also store symbol_class
and aux record when a PE weak external with aux meets an
existing undefined hash entry.
(_bfd_coff_generic_relocate_section): Also resolve weak alias
fallback for undefined symbols with C_NT_WEAK class and aux.
Jiawei [Tue, 30 Jun 2026 16:24:20 +0000 (00:24 +0800)]
RISC-V: Fix zvdota altfmt disassemble format issue
Fix-up vtype altfmt disassembly extension check.
Only print the altfmt vtype names when the object advertises one of the
extensions that defines that encoding, or when disassembling with all
extensions enabled.
Validated with:
make check RUNTEST=... RUNTESTFLAGS="riscv.exp"
Result:
PASS: gas/riscv/vector-insns
PASS: gas/riscv/zvdota
# of expected passes: 360
gas/ChangeLog:
* testsuite/gas/riscv/zvdota.d: Fix format.
opcodes/ChangeLog:
* riscv-dis.c (riscv_vtype_altfmt_supported): Add ext check.
(print_insn_args): Use altfmt check.
Jiawei [Tue, 30 Jun 2026 13:55:11 +0000 (07:55 -0600)]
RISC-V: Add Zvbdota extension support
This patch supports the RISC-V Zvbdota family of batched dot-product
extensions [1].
Compared to the non-batched Zvdota family, Zvbdota computes up to eight
dot products at a time. These instructions use an EMUL=8 `vs2` vector
register group and a scaled-by-8 `ci` immediate encoded in `vs2[2:0]`.
This patch adds assembler/disassembler support for those additional
operand constraints.
The Zvbdota extension family includes the following extensions:
* Zvqwbdota8i: batched dot product of 8-bit integers with 32-bit
accumulation.
* Zvqwbdota16i: batched dot product of 16-bit integers with 64-bit
accumulation.
* Zvfwbdota16bf: batched dot product of bfloat16 floating-point numbers
with 32-bit accumulation.
* Zvfqwbdota8f: batched dot product of 8-bit floating-point numbers with
32-bit accumulation.
* Zvfbdota32f: batched dot product of 32-bit single-precision
floating-point numbers with 32-bit accumulation.
Jiawei [Tue, 30 Jun 2026 13:54:21 +0000 (07:54 -0600)]
RISC-V: Add Zvdota extension classes
Zvfqwdota8f: dot product of 8-bit floating-point numbers with 32-bit accumulation.
Zvdota also uses the vtype alternative format bit, altfmt, which is bit 8 of the vtype CSR. This patch adds symbolic e8alt and e16alt vsew constants for vsetvli/vsetivli so that assembly code can select the alternative element formats required by these dot-product instructions.
Alan Modra [Tue, 30 Jun 2026 02:56:46 +0000 (12:26 +0930)]
ld testsuite alpha_ld_flags
This is how alpha can use -Ttext-segment on just those tests that need
it. And since the way run_dump_test uses $opts(ld) allows tcl procs to
be embedded, there is no need to specially expand [big_or_little_endian].
binutils/
* testsuite/lib/binutils-common.exp (run_dump_test <opts(ld)>): No
need to handle big_or_little_endian specially.
ld/
* testsuite/ld-elf/elf.exp (alpha_ld_flags): New proc.
(LDFLAGS): Don't set -Ttext-segment for alpha globally.
* testsuite/ld-elf/compress1a.d: Add alpha_ld_flags.
* testsuite/ld-elf/compressed1a.d: Likewise.
* testsuite/ld-elf/eh5.d: Likewise.
projects / thirdparty / binutils-gdb.git / log
