Pedro Alves [Wed, 20 May 2026 10:22:56 +0000 (11:22 +0100)]
Adjust gdb.python/py-events.exp for Cygwin/MinGW, "info proc" => "inferior"
The testcase is using "info proc" to extract the inferior's process
ID. But "info proc" does not exist on all targets, including Windows.
Switch to using the get_inferior_pid routine from lib/gdb.exp, which
uses "inferior" instead.
With this fixed, the testcase passes cleanly on Cygwin. I haven't
tested on MinGW (I'm not set up for Python testing there currently),
but at least (since the previous patches) the test should be able to
compile & run there now.
Pedro Alves [Wed, 20 May 2026 10:22:56 +0000 (11:22 +0100)]
Adjust gdb.python/py-events.exp for Cygwin/MinGW, no fork
The gdb.python/py-events.exp testcase currently uses fork, and relies
on "set detach-on-fork off".
Cygwin does support the fork syscall, but GDB can't follow forks
there, so "detach-on-fork off" has no effect. And also, there is no
fork on native Windows, which makes the testcase unusable on MinGW
currently.
I don't see any reason the testcase needs to use fork or multiple
inferiors. We can replace what those parts were testing by more
focused tests:
- The clear_objfiles event was tested via following a fork. Instead,
test a more directed "file" command.
- Two-inferior quit was being used to test that gdb.ExitedEvent has
no "exit_code". Quitting while an inferior is being debugged makes
GDB kill the inferior. What's really being tested is the kill
path, so write an explicit (single-inferior) kill test.
Pedro Alves [Wed, 20 May 2026 10:45:57 +0000 (11:45 +0100)]
Windows gdb+gdbserver: Decode Cygwin ExitProcess codes
On native Cygwin, GDB misreports the inferior's exit reason in several
common cases, resulting in several gdb.base/exitsignal.exp failures:
$ grep FAIL gdb.sum
FAIL: gdb.base/exitsignal.exp: how=run: signal: program terminated with SIGSEGV (the program exited)
FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitsignal is 11 (SIGSEGV) after SIGSEGV.
FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitcode is still void after SIGSEGV
FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitsignal is 11 (SIGSEGV) after restarting the inferior
FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitcode is still void after restarting the inferior
FAIL: gdb.base/exitsignal.exp: how=run: normal: continue to exit
FAIL: gdb.base/exitsignal.exp: how=run: normal: $_exitcode is one after normal inferior is executed
FAIL: gdb.base/exitsignal.exp: how=run: normal: $_exitsignal is still void after normal inferior is executed
FAIL: gdb.base/exitsignal.exp: how=attach: normal: continue to exit (the program exited)
FAIL: gdb.base/exitsignal.exp: how=attach: normal: $_exitcode is one after normal inferior is executed
For example, from gdb.log, the normal exit case:
...
[Thread 14300.0x4214 (id 1) exited with code 1]
[Thread 14300.0x1b1c (id 4) exited with code 1]
[Thread 14300.0x1e2c (id 2) exited with code 1]
Program terminated with signal SIGHUP, Hangup.
The program no longer exists.
(gdb) FAIL: gdb.base/exitsignal.exp: how=run: normal: continue to exit
The program in fact exited normally with code 1. SIGHUP happens to be
signal 1, and GDB picked the wrong interpretation.
Similarly, for the signal termination case:
...
continue
Continuing.
[Thread 4600.0x3104 (id 4) exited with code 2816]
[Thread 4600.0x2bcc (id 3) exited with code 2816]
[Thread 4600.0x2f44 (id 1) exited with code 2816]
[Inferior 1 (process 4600) exited with code 05400]
(gdb) FAIL: gdb.base/exitsignal.exp: how=run: signal: program terminated with SIGSEGV (the program exited)
Here the inferior died with SIGSEGV, but GDB reported exit decimal
2816 / octal 05400 / hex 0x0B00, which is SIGSEGV swapped into the
high byte of a waitpid exit status.
The problem is that Cygwin waitpid exit status and Windows exit codes
do not have the same encoding, and GDB & GDBserver do not know about
this.
This commit fixes it. It adds a Cygwin-specific branch to the code
that determines the terminating signal and status of a program. The
branch for native Windows/MinGW GDB is left intact, no behavior change
there.
The way to decode the exit codes is a little bit tricky, see detailed
comments added by the patch. To exercise the "raw NTSTATUS error
code" path in windows_process_info::exit_process_to_target_status,
gdb.base/exitsignal.exp is extended to debug a native Windows program
that crashes with a segfault (STATUS_ACCESS_VIOLATION).
With this, gdb.base/exitsignal.exp passes cleanly on Cygwin.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: Icaebcc234b71927915c996fd120884604441415b
Pedro Alves [Wed, 20 May 2026 10:45:57 +0000 (11:45 +0100)]
Windows gdb+gdbserver: Share exit status logic
Move the exit status logic added by commit 559e7e5056 ("Improve
process exit status macros on MinGW") from both GDB and GDBserver to a
shared routine used by both.
The next patch extends this routine with Cygwin-specific decoding.
Pedro Alves [Sat, 23 May 2026 01:01:12 +0000 (02:01 +0100)]
gdb.base/exitsignal.exp: Test attaching too
On some targets, like Cygwin (see the following commit), extracting
the exit code works differently depending on whether the inferior was
run by GDB, or GDB attached to an existing process. Extend
gdb.base/exitsignal.exp to test both scenarios.
Note: We add a wait_for_gdb sleep loop to segv.c and normal.c so the
attach path can synchronize with GDB before the inferior runs. For
simplicity, the run path pokes the same variable from setup, so
behavior there is unchanged.
The testcase passes cleanly on Linux, native and gdbserver, and on
MinGW too. Cygwin still requires more fixes.
Pedro Alves [Sat, 23 May 2026 01:01:12 +0000 (02:01 +0100)]
gdb.base/exitsignal.exp: Exit with non-zero
gdb.base/exitsignal.exp currently tests exiting with exit code 0.
But, testing for 0 is typically more "dangerous" in the sense that
it's easy for some bug in GDB or the target backend to fail to extract
the exit code and return 0. Make it test exit code 1 instead.
gdb.base/coredump-filter-build-id.exp currently reuses normal.c. It
could still use it with this patch, but it seems better to me to
remove the coupling. Simply add a new .c file for that testcase,
which still returns 0.
Pedro Alves [Sat, 23 May 2026 01:01:12 +0000 (02:01 +0100)]
Adjust gdb.base/exitsignal.exp for MinGW, separate program names
Currently, gdb.base/exitsignal.exp on MinGW skips half the tests, like
so:
# of expected passes 13
# of untested testcases 1
... because the testcase actually compiles two programs, but the
second program is compiled using the same executable name as the
first, at a time when gdb still has the first executable open,
resulting in:
.../x86_64-w64-mingw32/bin/ld.exe: cannot open output file C:/.../gdb.base/exitsignal/exitsignal.exe: Permission denied
The use of standard_testfile in the middle of a testcase is a bit
surprising. Fix this by moving the second compilation to the top, and
give each executable its own name.
Move the bulk of test code to two procedures, one for testing exiting
with signal, another for testing normal exit.
With this, gdb.base/exitsignal.exp passes cleanly on
x86_64-w64-mingw32.
Pedro Alves [Sat, 23 May 2026 02:08:31 +0000 (03:08 +0100)]
Adjust gdb.base/exitsignal.exp for MinGW, second-chance SIGSEGV
On native Windows a segmentation fault is delivered as a SEH
exception, so GDB stops twice: once for the first-chance exception,
and -- if no SEH handler in the inferior catches it -- again for the
second-chance exception, after which the process dies. The testcase
currently continues only once, resulting in:
...
continue
Continuing.
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff765ac1469 in main (argc=1, argv=0x9f2640) at C:/rocgdb/src.cascais-rsync/gdb/testsuite/gdb.base/segv.c:24
24 *(volatile int *) 0;
(gdb) PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
continue
Continuing.
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff765ac1469 in main (argc=1, argv=0x9f2640) at C:/rocgdb/src.cascais-rsync/gdb/testsuite/gdb.base/segv.c:24
24 *(volatile int *) 0;
(gdb) FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV
...
Add a second continue on MinGW to step past the second-chance stop.
With this, gdb.base/exitsignal.exp passes cleanly on MinGW:
-FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV
+PASS: gdb.base/exitsignal.exp: trigger SIGSEGV, second-chance
+PASS: gdb.base/exitsignal.exp: program terminated with SIGSEGV
Pedro Alves [Sat, 23 May 2026 02:08:31 +0000 (03:08 +0100)]
Adjust gdb.base/exitsignal.exp for MinGW, trigger fault
gdb.base/segv.c uses raise(SIGSEGV) to generate a SIGSEGV. On native
Windows that does not generate an EXCEPTION_ACCESS_VIOLATION; raise is
a pure userspace construct: it dispatches to the registered SIGSEGV
handler if there is one, otherwise calls abort. GDB therefore never
sees an exception to intercept. E.g.:
...
continue
Continuing.
[Thread 1908.0x3308 (id 2) exited with code 3]
[Inferior 1 (process 1908) exited with code 03]
(gdb) FAIL: gdb.base/exitsignal.exp: trigger SIGSEGV (the program exited)
continue
The program is not being run.
...
Replace the raise with a real null dereference so the kernel actually
raises an access violation.
Note: I confirmed no other tests use segv.c. segv.c and normal.c are
both "owned" by gdb.base/exitsignal.exp.
Lancelot SIX [Tue, 16 Apr 2024 08:26:36 +0000 (09:26 +0100)]
gdb/amd-dbgapi-target: Update xfer_partial to always use dbgapi
On the Windows platform, the entire "global" address space is not
mapped in the inferior memory. For such configuration, part of the
global address space lives in GPU memory, and can only be accessed via
rocm-dbgapi.
This patch updates amd_dbgapi_target::xfer_partial so it always calls
into amd-dbgapi to access the global address space. GDB will still be
called to access host memory using xfer_global_memory callback.
To be sure that the callback request is not routed back to dbgapi, the
xfer_global_memory callback is modified to route the request to
whichever target sits below the amd-dbgapi target on the target stack.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I2d5ca46edf65e2dec3606d18f7ad1d22d0275a63
Lancelot SIX [Wed, 8 May 2024 10:15:22 +0000 (11:15 +0100)]
gdb/amd-dbgapi-target: Move Linux code to amd-dbagapi-posix-hdep.c
The current amd-dbgapi-target.c file contains some code that is Linux
specific. This patch extracts such code to host dependent files, so
they can be replaced for other host platforms.
The code in question is related to the event loop. The way dbgapi
notifies GDB that there is a pending event is platform specific. For
Linux (the only platform supported so far), this is done using a file
descriptor GDB can use in its main event loop.
This patch introduces an overall host-dependency infrastructure and
moves the Linux-specific code to amd-dbgapi-posix-hdep.c. The "posix"
naming is because even though only Linux is supported, the code is
really plain POSIX code that would work on other POSIX platforms.
This also follows the existing posix-hdep.c nomenclature.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Id3d4b947176e5cfe91b0ab64376fca1a6a8c6fc9
Tom de Vries [Fri, 12 Jun 2026 10:41:08 +0000 (12:41 +0200)]
[gdb/build, clang] Fix ignored aligned attribute
PR build/34279 reports a build failure with clang.
This is a regression since commit 6c85ef111b0 ("[gdb] Use using instead of
typedef"), which did:
...
-typedef long __attribute__ ((__aligned__ (4))) compat_x32_clock_t;
+using compat_x32_clock_t = long __attribute__ ((__aligned__ (4)));
...
Richard Earnshaw [Thu, 11 Jun 2026 13:50:13 +0000 (14:50 +0100)]
gas: deprecate .vtable_entry and .vtable_inherit
These ELF directives were a GNU extension to support the C++ ABI
that was in use before the introduction of the generic C++ ABI in
GCC-3.0. They're obsolete now and many newer targets simply
do not provide the back-end support for them.
Flag them as deprecated in the NEWS file, and remove the documentation
for them. Warn (once) if the directive is used in a source file.
Alan Modra [Thu, 11 Jun 2026 23:02:18 +0000 (08:32 +0930)]
PR 30308 yet again
Commit cc28c46227cd removed the symbol_resolving recursion guards in
i386_intel_simplify_symbol. The testcases we'd considered then just
involved simple equates, handled by symbol_equated_to. However, more
complex expressions can also cause unbounded recursion. This patch
restores the recursion guards.
This patch adds support for native microblazeel-linux-gdb including
support for debugging with core dump files. Code is based on Xilinx/AMD
git repository used for Yocto builds with changes for proper indentation
and removal of commented out code.
Testing with native gdb has been checked to be working. Can load and run
a program using commands like break, step and finish. When a core file is
specified to gdb; registers can be examined using info reg. Tested using
qemu-system-microblazeel from AMD/Xilinx Yocto 2025.2 release.
Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com> Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com> Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com> Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com> Signed-off-by: Michael J. Eager <eager@eagercon.com>
Alan Modra [Thu, 11 Jun 2026 01:40:40 +0000 (11:10 +0930)]
mips-coff: mips_reflo_reloc buffer overflow
Like commit c2cb1bfb901e, but for mips-coff. Make the hi reloc list
per-section rather than per-file, since fuzzers can generate objects
with cross-section refs where the hi reloc section data is freed
before the lo relocs are processed.
Also properly sanity check the hi reloc offset.
* libecoff.h (struct ecoff_tdata): Move mips_refhi_list to..
(struct ecoff_section_tdata): ..here.
(ecoff_section_data): Remove unused abfd arg.
* coff-alpha.c (alpha_relocate_section): Update ecoff_section_data.
* coff-mips.c (mips_refhi_reloc): Use bfd_reloc_offset_in_range.
Allocate ecoff_section_data as necessary. Use that instead of
bfd tdata.
(mips_reflo_reloc): Adjust to suit tdata change.
* ecoff.c (_bfd_ecoff_bfd_free_cached_info): Likewise.
Jon Turney [Thu, 4 Jun 2026 13:22:37 +0000 (14:22 +0100)]
ld: doc: Use consistent language for 'PE target'-only options
It seems like the 'i386 PE targeted' phrasing probably predates x86_64
PE support in binutils, and should have been touched when that was
added.
Even loosely interpreting that phrase to mean 'those two Intel
architectures, you know what I mean', this is less than helpful now that
PE aarch64 is a possibility.
Change the use of various phrases like '[This is an i386 PE specific
option]' to conistently use '[This option is specific to PE targeted
ports of the linker]' nearly everywhere.
The only options that really are specific in this way are
'--large-address-aware' (PE only) and '--high-entropy-va' (PE+ only), so
annotate those appropriately.
Do an editing pass of the various other mentions of 'PE'.
Also, add the 'PE only' annotation to the description of
'--leading-underscore' in the 'Options Specific to PE Targets' section,
to be consistent with all the others.
Also, since we've already mentioned that all the DllCharacteristics
flags are PE-specific, don't awkwardly mention it (again) as part of the
note about what Windows version support for that flag was introduced in.
Future work: the phrase 'PE targeted port of the linker' seems a bit
off, since cross-tools are a thing. Should it just be 'PE targeted linker'?
2026-06-01 Jon Turney <jon.turney@dronecode.org.uk>
* ld.texi (Options): Use consistent language for 'PE target'-only
options.
Tom Tromey [Tue, 9 Jun 2026 12:51:02 +0000 (06:51 -0600)]
Sort symtabs using their display filename
While working on gnat-llvm, I found that many tests in
gdb.ada/info_auto_lang.exp were failing. Investigating this, the
difference turned out to be a different sort order for the output. I
then tracked this down to gnat-llvm emitting:
<108b> DW_AT_name : (indirect line string, offset: 0x10f): /home/tromey/gdb/binutils-gdb/gdb/testsuite/gdb.ada/mi_dyn_arr/pck.adb
<108f> DW_AT_comp_dir : (indirect line string, offset: 0): /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.ada/mi_dyn_arr
This distinction isn't relevant to the test, so I tried "set
filename-display basename". However, this setting had no effect.
It seems to me that, for "info types" and the like, the output should
be sorted according to the user's display preferences. This patch
implements this and adds a new DWARF assembler test.
Finally, this updates info_auto_lang.exp to be insensitive to this
quirk of gnat-llvm.
Andrew Burgess [Wed, 10 Jun 2026 18:43:24 +0000 (19:43 +0100)]
gdb/testsuite: remove debug output messages from testsuite
Over time I've managed to leave various debug logging messages in the
testsuite, all of which include the 'APB' tag that I use to make
searching for these easier. None of these were required, they could
all be removed.
I have left the logging output in gdb.base/stap-probe.exp (but with
the 'APB' removed) as it looked slightly useful, and it's harmless to
keep it. But all of the other logging lines I just removed.
There should be no change in what is tested after this commit.
Sébastien Darche [Thu, 21 May 2026 15:12:17 +0000 (11:12 -0400)]
gdb/breakpoint: remove assertion when printing internal breakpoints without locspecs
When debugging gdb with `set debug breakpoint on`, gdb would crash if
the inferior happened to unload (through dlclose ()) a shared library
that contains jit debugging symbols:
../../gdb/breakpoint.c:6473: internal-error: print_breakpoint_location:
Assertion `b->locspec != nullptr || (!user_breakpoint_p (b) && (b->type
== bp_shlib_event || b->type == bp_thread_event))' failed.
A problem internal to GDB has been detected [...]
This assertion was added in commit 5770f68 ("gdb: handle empty locspec
when printing breakpoints"). The assumption for this assert is that the
user may not call any (gdb-)debugging command between the time a shared
library is marked (bp_location->shlib_disabled is set) and the
breakpoint is actually removed. This would be true if the user called
`maint info breakpoints` as explained in the original commit message.
However, if `set debug breakpoint on` is called, gdb prints debugging
info as the shared library is being unloaded. The ~jiter_objfile_data
dtor deletes the breakpoint, which calls remove_breakpoint_1 on the
bp_location in the recently unloaded shared object. Since `debug
breakpoint` is enabled, we go through print_breakpoint_location with the
bp_location's shlib_disabled flag set, which results in the assert
above.
This commit removes the assertion as it is not true in all cases. I've
also included a minimal test case that loads a shared library with a
__jit_debug_register_code symbol. The test fails with the assert.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: Ia19c84f194a6f0c10315548c7f423bfd86ef0266
Tom de Vries [Wed, 10 Jun 2026 09:11:53 +0000 (11:11 +0200)]
[gdb/contrib] Fix UnicodeDecodeError in dwarf-to-dwarf-assembler.py
When running dwarf-to-dwarf-assembler.py on outputs/gdb.rust/unicode/unicode,
I run into a UnicodeDecodeError for (using readelf -w):
...
<4><9cf>: Abbrev Number: 10 (DW_TAG_variable)
<9d3> DW_AT_name : (indirect string, offset: 0xab4): 𝕯
...
or more explicit using llvm-dwarfdump -v:
...
0x000009cf: DW_TAG_variable [10] (0x000009c2)
DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000ab4] \
= "\360\235\225\257")
...
Fix this by using UTF-8 instead of ascii decoding, which gets us instead:
...
DW_AT_name 𝕯 DW_FORM_strp
...
Tom de Vries [Wed, 10 Jun 2026 07:54:22 +0000 (09:54 +0200)]
[gdb/contrib] Fix ELFParseError in dwarf-to-dwarf-assembler.py
When running dwarf-to-dwarf-assembler.py on
outputs/gdb.dwarf2/implptr-64bit/implptr-64bit-d2-o8-a4-r4-t0, I run into:
...
elftools.common.exceptions.ELFParseError: expected 8, found 5
...
for the DWARF:
...
<2><335>: Abbrev Number: 8 (DW_TAG_variable)
<336> DW_AT_name : p
<338> DW_AT_location : 6 byte block: f2 14 3 0 0 0 \
(DW_OP_GNU_implicit_pointer: <0x314> 0)
...
Pyelftools expects that DW_OP_GNU_implicit_pointer has an 8-byte reference
operand (because it's a 64-bit DWARF unit), but instead it has a 4-byte
reference.
The DWARF is correct, it's a cornercase of using DW_OP_GNU_implicit_pointer in
DWARF v2, where DW_FORM_ref_addr references have the same size as an address
on the target system, something that was changed in DWARF v3.
Handle this by catching the error and printing:
...
DW_AT_location "\xf2\x14\x03\x00\x00\x00" DW_FORM_block \
# Failed to print DWARF expression: expected 8, found 5
...
Tom de Vries [Wed, 10 Jun 2026 07:54:22 +0000 (09:54 +0200)]
[gdb/contrib] Fix KeyError in dwarf-to-dwarf-assembler.py
Executable outputs/gdb.threads/stepi-over-clone/stepi-over-clone contains the
following DWARF (using readelf -w):
...
<31c5> DW_AT_const_value : 8 byte block: ff ff ff ff ff ff ff ff
...
or more explicit using llvm-dwarfdump -v:
...
DW_AT_const_value [DW_FORM_block1] \
(<0x08> ff ff ff ff ff ff ff ff )
...
Before commit 18ad8c1a54d ("Emit DWARF expressions from
dwarf-to-dwarf-assembler.py"), the dwarf-to-dwarf-assembler.py script
generated:
...
DW_AT_const_value { MANUAL: Fill expr list } SPECIAL_expr
...
for this.
But since the commit, we run into a KeyError.
The problem is that we're trying to interpret some random data as a DWARF
expression.
Fix this by special-casing DW_AT_const_value, and generating instead:
...
DW_AT_const_value "\xff\xff\xff\xff\xff\xff\xff\xff" DW_FORM_block1
...
which mimics the style I found in gdb.dwarf2/info-locals-optimized-out.exp:
...
DW_TAG_variable {
DW_AT_name const_bytes
DW_AT_type :$int_type_label
DW_AT_const_value "\x01\x01\x01\x01" DW_FORM_block1
}
...
Likewise for DW_AT_discr_list.
Another case for which the KeyError triggers, is DWARF from
outputs/gdb.ada/array_of_variant/p-minimal:
...
<2><14a4>: Abbrev Number: 20 (DW_TAG_structure_type)
<14a5> DW_AT_name : p__payload_t
<14a9> DW_AT_byte_size : 18 byte block: \
fd 63 14 0 0 97 94 1 99 45 0 0 0 23 7 9 fc 1a \
(DW_OP_GNU_variable_value: <0x1463>; \
DW_OP_push_object_address; \
DW_OP_deref_size: 1; \
DW_OP_call4: <0x1421>; \
DW_OP_plus_uconst: 7; \
DW_OP_const1s: -4; DW_OP_and)
...
because the pyelftools version that I'm using doesn't support
DW_OP_GNU_variable_value yet (supported starting v0.33).
Fix this by catching the KeyError, and falling back to the string case:
...
DW_AT_byte_size \
"\xfd\x63\x14\x00\x00\x97\x94\x01\x99\x45\x00\x00\x00\x23\x07\x09\xfc\x1a" \
DW_FORM_exprloc # Failed to print op as DWARF expression: 0xfd
...
Alan Modra [Wed, 10 Jun 2026 02:10:59 +0000 (11:40 +0930)]
PR 34204 dlltool SEGVs with --exclude-symbols
This fixes a segfault introduced by commit 45a7f5a29de7 which didn't
take into account that there was a use of leading_underscore in option
processing.
PR 34204
* dlltool.c (struct string_list): Make string a flexible array
member.
(add_excludes): Adjust to suit. Extract code adding underscore
and informing..
(underscore_excludes): ..to here. New function.
(main): Call underscore_excludes.
Markus Metzger [Thu, 20 Nov 2025 11:21:41 +0000 (11:21 +0000)]
gdb, btrace: support libipt v2.2 events
Add support for printing new events added in libipt v2.2 originating from
Event Tracing in combination with Flexible Return and Event Delivery
(FRED) and from Trigger Tracing.
Reviewed-By: Keith Seitz <keiths@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom Tromey [Tue, 9 Jun 2026 13:36:37 +0000 (07:36 -0600)]
Make two Ada tests more robust
tasks.exp and task_watch.exp were failing when run with gnat-llvm.
Investigating these showed the same problem (which makes sense because
the tests use the same program). In this code:
for J in Task_List'Range loop -- STOP_HERE
Task_List (J).Call_Break_Me;
end loop;
... with GCC, the breakpoint set on the 'for' line is only hit a
single time. However, with gnat-llvm, the breakpoint is hit on every
iteration of the loop. IMO this is a GCC bug.
Similarly, at the end of the function:
null; -- STOP_HERE_2
... with gnat-llvm, a breakpoint set here was not being hit. It seems
perhaps somewhat strange to set a breakpoint on a null statement at
the end of a function; and while this might possibly be a gnat-llvm
bug, this isn't really the point of this test.
This patch makes these tests more robust by arranging for the
breakpoints to be set before the loop and on a call, respectively.
Because this is Ada-specific, was reviewed internally, and is just a
minor test case adjustment, I am checking it in.
Alan Modra [Sun, 7 Jun 2026 23:43:51 +0000 (09:13 +0930)]
Re: RISC-V: riscv_parse_subset_t's isa_spec is only parser input
check_compiler_available fails with a ld segfault linking
int main (void) { return 0; }
Program received signal SIGSEGV, Segmentation fault.
0x0000000000466a64 in riscv_parse_add_subset (rps=rps@entry=0x7fffffffd450, subset=subset@entry=0x962ca0 "zaamo", major=-1, minor=-1, implicit=implicit@entry=true) at /home/alan/src/binutils-gdb/bfd/elfxx-riscv.c:1947
1947 riscv_get_default_ext_version (*rps->isa_spec, subset,
(gdb) p rps->isa_spec
$1 = (const enum riscv_spec_class *) 0x0
This was triggered when calling riscv_merge_attributes for crti.o
which had
(gdb) p ibfd->tdata.elf_obj_data->known_obj_attributes[OBJ_ATTR_PROC][Tag_RISCV_arch]
$5 = {type = 2, i = 0, s = 0x97e4c0 "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zmmul1p0"}
Fix the segfault by reinstating a NULL check removed with commit 413cf36d8e81
Alan Modra [Sat, 6 Jun 2026 01:38:11 +0000 (11:08 +0930)]
filter_implib_symbols
This tidies filter_implib_symbols implementations, which I noticed
returned unsigned int but took long symbol counts. While unsigned int
is very likely sufficient, size_t is better.
_bfd_elf_filter_global_symbols is a linker-only function so really
should be moved to elflink.c, but I left it in elf.c as it calls
sym_is_global, a static function in elf.c.
* elf-bfd.h (struct elf_backend_data): Take size_t symcount
and return a size_t from elf_backend_filter_implib_symbols.
(_bfd_elf_filter_implib_symbols): Likewise. Rename from
_bfd_elf_filter_global_symbols.
* elf.c (_bfd_elf_filter_implib_symbols): Likewise. Use
size_t vars too, and avoid unnecessary casts.
* elf32-arm.c (elf32_arm_filter_cmse_symbols): Likewise.
(elf32_arm_filter_implib_symbols): Likewise.
* elflink.c (elf_output_implib): Avoid unneccesary casts.
Call elf_backend_filter_implib_symbols uncontitionally.
* elfxx-target.h (elf_backend_filter_implib_symbols): Define
fallback as _bfd_elf_filter_implib_symbols.
Alan Modra [Sat, 6 Jun 2026 01:36:40 +0000 (11:06 +0930)]
Drop output bfd param from many elf linker functions
Functions that are always passed a non-NULL bfd_link_info* and are not
called by BFD_SEND using the output bfd, need not pass the output bfd
as a parameter. It can be accessed via info->output_bfd. Removing
the excess parameters result in a small code size reduction on
x86_64-linux --enable-targets=all ld built with a static libbfd, from 9896133 to 9893805 bytes.
Alan Modra [Sat, 6 Jun 2026 01:35:45 +0000 (11:05 +0930)]
gas s_comm_internal uninitialised access
After elf_common_parse calls ignore_rest_of_line on some errors,
s_comm_internal calls demand_empty_rest_of_line. These functions
cannot be both called, as they consume the end_of_stmt char in the
input buffer and the second call then consumes the next line of input,
which may not even be in the input buffer.
Tom Tromey [Fri, 22 May 2026 17:17:17 +0000 (11:17 -0600)]
Emit DWARF expressions from dwarf-to-dwarf-assembler.py
This changes dwarf-to-dwarf-assembler.py to attempt to emit DWARF
expressions. It is not close to perfect, since it relies on the
elftools formatting to some extent, but it does at least eliminate the
need to do a separate "readelf" step to try to work on the expression
by hand.
Tom Tromey [Wed, 22 Apr 2026 18:31:57 +0000 (12:31 -0600)]
Use double quotes in some gdb output
I looked for spots where gdb was using `...' or ``...'' quoting, and
changed these to use double quotes instead.
I think it might be good to regularize output quoting in gdb. My
proposal is to use double quotes, though single quotes would also be
fine. Using `...', though, is a kind of older style and has fallen
out of favor in GNU; the relevant node is here:
Tom de Vries [Fri, 5 Jun 2026 21:06:48 +0000 (23:06 +0200)]
[gdb] Drop nullptr in "get_selected_frame (nullptr)"
I came across "get_selected_frame (nullptr)", and realized nullptr is the
default argument, so this can be simplified to "get_selected_frame ()".
Do so using the following script:
...
$ find gdb* -type f -name "*.[ch]" -o -name "*.cc" \
| xargs sed -i 's/get_selected_frame (nullptr)/get_selected_frame ()/'
...
and likewise for "get_selected_frame (NULL)".
Tom de Vries [Fri, 5 Jun 2026 21:03:42 +0000 (23:03 +0200)]
[gdb/build] Fix Wnon-pod-varargs in bppy_repr
I build gdb with clang and ran into a build breaker:
...
gdb/python/py-breakpoint.c:1074:52: error: cannot pass object of non-trivial \
type 'const std::string' (aka 'const basic_string<char>') through variadic \
function; call will abort at runtime [-Wnon-pod-varargs]
1074 | return PyUnicode_FromFormat ("<%s (invalid)>", tp_name);
| ^
...
This looks like fallout from commit dafd73bcda6 ("gdb/python: fix memory leak
in gdb_py_tp_name"), which changed the return type of gdbpy_py_obj_tp_name
from const char * to std::string.
We could fix this using tp_name.c_str (), but instead fix this by simplifying
the code using gdb_py_invalid_object_repr.
Tom Tromey [Wed, 3 Jun 2026 19:03:31 +0000 (13:03 -0600)]
Add two new warnings to warning.m4
I recently learned that GCC has improved -Wdangling-reference and
added -Wunterminated-string-initialization. Both of these seem
sensible to me, so this patch adds them to warning.m4.
gdb rebuilds cleanly with this in place on x86-64 Fedora 43.
Tom de Vries [Fri, 5 Jun 2026 12:18:59 +0000 (14:18 +0200)]
[gdb/testsuite] Add missing copyright notice in tclint-plugin.py
I ran:
...
$ ./gdb/contrib/license-check-new-files.sh -s gdb-17-branchpoint HEAD
Scanning directories gdb*/...
gdb/features/aarch64-fpmr.c: None
gdb/features/aarch64-fpmr.xml: FSFAP-no-warranty-disclaimer
gdb/syscalls/riscv-linux.xml: FSFAP
gdb/syscalls/riscv-linux.xml.in: FSFAP-no-warranty-disclaimer
gdb/testsuite/tclint-plugin.py: None
gdbsupport/unordered_dense/stl.h: MIT
...
and found out that I forgot to add a copyright notice to
gdb/testsuite/tclint-plugin.py.
The sole size dependent parameter used there is ARCH_SIZE. For just this
there's no good reason to build all of the involved code twice. Make the
value a function parameter instead.
Jan Beulich [Fri, 5 Jun 2026 09:11:40 +0000 (11:11 +0200)]
RISC-V: drop dead code from subset parsing
In riscv_update_subset1(), when explicit_subset is NULL, errmsg_internal
is the empty string. There's no need then to pass this as an extra
argument to the error handler.
riscv_parsing_subset_version() can't return NULL. Dropping the respective
checks clarifies that there is no issue with a missing error message (gas
would rely on one being emitted when parsing fails).
Jan Beulich [Fri, 5 Jun 2026 09:10:28 +0000 (11:10 +0200)]
RISC-V: error handling for subset parsing
The parsing of both the argument of -march= and the operand(s) of
".option arch, ..." can fail. In such a case for .option (and equally
for .attribute) prior state should continue to be used, while for -march=
defaults should be put in place. In particular, extensions conflicting
with previously enabled extensions should not suddenly become available.
While re-indenting riscv_set_rvc() invocations, leverage that C implies
Zca (and hence a check for the latter suffices). Mirror that change to
riscv_set_arch() for consistency.
Jan Beulich [Fri, 5 Jun 2026 09:10:12 +0000 (11:10 +0200)]
RISC-V: riscv_parse_subset_t's isa_spec is only parser input
Make the field pointer-to-const and drop indirection from
riscv_get_default_ext_version(). This way it's more clear that parsing
won't alter the field.
Jan Beulich [Fri, 5 Jun 2026 09:09:55 +0000 (11:09 +0200)]
RISC-V: riscv_set_arch() can fail
In that case neither riscv_rps_as.subset_list nor file_arch_str would be
set, yet the NULL pointers would be happily passed into functions not
expecting such.
Jan Beulich [Fri, 5 Jun 2026 09:09:38 +0000 (11:09 +0200)]
RISC-V: match_*() improvements
Match functions referenced by macro insns should not
unconditionally invoke match_opcode(): The macro enumeration can change
(grow), making the function potentially yield false negatives.
In match_rs1_nonzero(), used solely by macro insns, add an assertion to
that effect.
While there also drop the pointless attribute from
match_rs1_nonzero_rs2_even()'s first parameter.
Jan Beulich [Fri, 5 Jun 2026 09:09:18 +0000 (11:09 +0200)]
RISC-V: fold redundant code in riscv_ip()
The parsing of 'F' and 'O' .insn operands is pretty redundant. Have only a
single instance each of common code, with the inner switch()es merely
handling the actual value insertion. This in particular simplifies the
addition of new sub-forms.
Jan Beulich [Fri, 5 Jun 2026 09:08:48 +0000 (11:08 +0200)]
RISC-V: rename operand descriptor O4
It's describing a 7-bit field, so O7 is the more consistent (with other
O<n> and F<n>) name. This way a subsequent change will also be a little
easier.
Matthieu Longo [Tue, 26 May 2026 10:46:29 +0000 (11:46 +0100)]
gdb/python: fix memory leak in gdb_py_tp_name
The current implementation of gdb_py_tp_name() leaks a reference to the
object returned by PyType_GetFullyQualifiedName() for Python >= 3.13, and
PyType_GetQualName() for Python >= 3.11.
Managing the strong reference on the returned PyObject* with a gdbpy_ref<>
fixes the reference count, but also causes the temporary object to be
deallocated on function exit. As a consequence, the 'const char *' returned
by PyUnicode_AsUTF8AndSize() becomes dangling and can no longer safely be
returned.
The proposed approach consists in changing gdb_py_tp_name() to return a
std::string, and forcing a copy of the 'const char *' value, statically
or dynamically allocated, stored in a temporary or non-temporary PyObject,
depending on the version of Python it was compiled with.
An unfortunate side effect of this fix is that every call sites where the
tp_name is printed, must now use `.c_str()' because PyErr_Format()
and its siblings cannot handle std::string.
Jon Turney [Fri, 22 May 2026 12:43:15 +0000 (13:43 +0100)]
ld: Drop pep-dll-{aarch64,x86_64}.c
When configuring with
'--enable-targets=x86_64-w64-mingw32,aarch64-w64-mingw32', many
duplicate symbol errors are produced:
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_dll_id_target':
> /wip/binutils-gdb/build/ld/../../ld/pe-dll.c:493: multiple definition of `pep_dll_id_target'; pep-dll.o:/wip/binutils-gdb/build/ld/../../ld/pe-dll.c:493: first defined here
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_dll_add_excludes':
> /wip/binutils-gdb/build/ld/../../ld/pe-dll.c:586: multiple definition of `pep_dll_add_excludes'; pep-dll.o:/wip/binutils-gdb/build/ld/../../ld/pe-dll.c:586: first defined here
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_find_data_imports':
> /wip/binutils-gdb/build/ld/../../ld/pe-dll.c:1444: multiple definition of `pep_find_data_imports'; pep-dll.o:/wip/binutils-gdb/build/ld/../../ld/pe-dll.c:1444: first defined here
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_dll_generate_def_file':
> /wip/binutils-gdb/build/ld/../../ld/pe-dll.c:1877: multiple definition of `pep_dll_generate_def_file'; pep-dll.o:/wip/binutils-gdb/build/ld/../../ld/pe-dll.c:1877: first defined here
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_create_import_fixup':
> etc.
On investigation, this is unsurprising, since we're compiling the same code twice. In
fact, configure.tgt has:
... so we're potentially including pep-dll.c compiled under three
different names!
I can't see anything in pe{,p}-dll.c which depends on the
COFF_WITH_peAArch64 or COFF_WITH_pex64 defines, so just remove all this.
(Neither pep-dll-aarch64.o or pep-dll-x86_64.o are listed in
ALL_EMUL_EXTRA_OFILES, so this multiple definition problem doesn't show
up when configured --enable-targets=all', but this seems like another
source of subtle bugs if those defines did do anything here...)
Cc'ed Evgeny (Hi!), because I think this crosses with not-yet-submitted
patches of his which do add some code conditional on COFF_WITH_peAArch64.
I imagine it's possible in code which *does* need to depend on the
output target to replace build time checks of COFF_WITH_pe{AArch64,x64}
with a runtime check of the output architecture (via
pe_details->pe_arch?).
Cc: Evgeny Karpov <evgeny.karpov@arm.com> Fixes: c60b3806799a ("aarch64-pe support for LD, GAS and BFD") Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
2026-05-29 Jon Turney <jon.turney@dronecode.org.uk>
Andrew Burgess [Tue, 19 May 2026 15:21:58 +0000 (16:21 +0100)]
gdb/frame: add FRAME_SCOPED_DEBUG_START_END
Add the FRAME_SCOPED_DEBUG_START_END macro, and make use of it in a
couple of places.
I find the frame debug output a little noisy, and it could be easier
to match up the entry/exit lines, by making use of
FRAME_SCOPED_DEBUG_START_END to print the frame level.
While I was adding the FRAME_SCOPED_DEBUG_START_END calls, there were
a couple of places where I also moved a variable declaration from the
top the a function into the function body. And in another couple of
places there was some debug output that could be removed, where the
existing debug just printed the frame level (this is now handled by
the START/END macro).
There should be no user visible changes after this commit unless 'set
debug frame on' is used of course.
zhaozhou [Mon, 25 May 2026 08:32:49 +0000 (16:32 +0800)]
LoongArch: Remove local hidden symbols testscase
Remove the local symbol ldh definitions with hidden visibility from the
relax-call36-*.s tests. The hidden visibility is meaningless for local
defined symbols and makes the test cases error.
Alan Modra [Wed, 3 Jun 2026 22:23:47 +0000 (07:53 +0930)]
elf_merge_st_other
This fixes a potential problem with merging non-visibility bits in
st_other. Non-visibilty bits in st_other have an architecture
dependent meaning, so they cannot just be copied from a foreign ELF
object file. I think the safest thing to do in this situation is
ignore non-visibility st_other bits. That's what this patch does.
PR 34062
* elflink.c (elf_merge_st_other): Replace abfd param with
obfd and ibfd parameters. Do not call
elf_backend_merge_symbol_attribute when input xvec differs
from output xvec.
(_bfd_elf_merge_symbol, _bfd_elf_add_default_symbol),
(elf_link_add_object_symbols),
(_bfd_elf_copy_link_hash_symbol_type): Pass both output bfd
and input bfd to elf_merge_st_other.
Alan Modra [Wed, 3 Jun 2026 22:22:44 +0000 (07:52 +0930)]
elflink.c: rename abfd and bed
This renames "abfd" function parameters to "obfd" when that parameter
is always the output bfd, and to "dynobj" when it is always the input
object used to attach dynamic sections. "bed" variables which are set
to the output bfd or dynobj backend data are renamed to "obed". (The
dynobj xvec must be the same as the output xvec, or bad things
happen.) The idea is to make the use of bfd* parameter a little more
obvious when reading the source.
Alan Modra [Tue, 2 Jun 2026 10:36:15 +0000 (20:06 +0930)]
spu: .note.spu_name
This fixes a bug with the .note.spu_name section flags, which were
made SEC_LOAD without SEC_ALLOC. That combination doesn't really make
sense and led to odd layout behaviour. In addition .note.spu_name
now uses the normal note alignment, with some tweaks to keep its file
offset 16 byte aligned. This tends to work better in the testsuite
when the standard scripts are not used and the note is merged with
other notes.
bfd/
* elf32-spu.c (spu_elf_create_sections): Remove SEC_LOAD from
.note.spu_name, and align to 4 bytes.
(spu_elf_fake_sections): Tweak .note.spu_name output section
alignment for layout.
(spu_elf_final_write_processing): New function.
(elf_backend_final_write_processing): Define.
binutils/
* testsuite/binutils-all/objcopy.exp (pr25662): Don't xfail spu.
ld/
* testsuite/ld-elf/orphan-region.d: Don't xfail spu.
* testsuite/ld-elf/pr23658-1e.d: Likewise.
* testsuite/ld-scripts/provide-8.d: Likewise.
* testsuite/ld-spu/ovl.d: Remove commented out old matches.
Adjust expected overlay file offset.
* testsuite/ld-spu/ovl2.d: Likewise.
The problem here is that gdb::remote_args::split expects a std::string,
and so ends up creating a std::string from ARGS. However, ARGS can be
NULL, e.g. if a user does this:
(gdb) maint test-remote-args
This ends up creating a std::string from a NULL pointer, which is
undefined behaviour.
Fix this by adding a check to test_remote_args_command, and throwing
an error if ARGS is NULL. Add a new test to verify this case.
Additionally, fix a typo in the header comment for
test_remote_args_command.
Ezra Sitorus [Mon, 1 Jun 2026 22:36:46 +0000 (23:36 +0100)]
gdb/aarch64: record/replay support for LRCPC3
FEAT_LRCPC3 introduces various load/store instructions with release
consistency for cases where ordering is required. This patch teaches GDB
to decode these instructions for recording and reversing.
The gdb.reverse/aarch64-lrcpc3.exp testcase verifies that the
instructions are recorded and correctly reversed. In particular, there
are some interesting cases to note:
* ldapur/stlur are SIMD instructions, but are not decoded in the simd
function.
* There are writeback cases to cover too. These were taken from the
binutils testcases: gas/testsuite/gas/aarch64/rcpc3.s.
The full testsuite was done on aarch64-none-linux-gnu without LRCPC3.
The gdb.arch and gdb.reverse tests were run on Shrinkwrap with LRCPC3
support.
Please note:
1) There is no support for LRCPC and LRCPC2 instructions
2) LRCPC3 is gated with +rcpc3 in GCC/binutils and LLVM.
Tom de Vries [Mon, 1 Jun 2026 18:14:37 +0000 (20:14 +0200)]
[gdb] Remove '/* *' multi-line comment marker
Doxygen supports a multi-line comment marker '/**'. In GDB we're using
something slightly similar: '/* *' [1].
Drop this and just use '/*'.
Result of:
...
$ find gdb* -type f -name "*.[ch]" -o -name "*.def" \
| egrep -v /testsuite/ \
| xargs sed -i 's%/\* \* %/* %'
...
and manually reverting the change in the comment for BINOP_MUL in
gdb/std-operator.def.
Tom de Vries [Mon, 1 Jun 2026 18:14:37 +0000 (20:14 +0200)]
[gdb/doc] Remove doxygen support
We have some form of doxygen support, allowing to run "make doxy" in
build/gdb/doc, but in the result I didn't find any references to gdbsupport
(moved to top-level in 2019), so I'm assuming this is unmaintained for a long
time now.
Remove it.
Reviewed-by: Kevin Buettner <kevinb@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34186
Tom de Vries [Mon, 1 Jun 2026 12:53:36 +0000 (14:53 +0200)]
[gdb/contrib] Add missing copyright notices
I found a few files in gdb/contrib that were missing a copyright notice.
In codespell-ignore-words.txt, it was trivial to add, but I found a
codespell issue stating that it's not explicitly support, so I added a note
about that.
In codespell-dictionary.txt, I had to resort to a hack, using an "empty word"
rewrite rule:
...
-># Comment here.
...
Also, I found that empty lines are not allowed in codespell-dictionary.txt. I
filed an issue about these two problems [1].
Since these two files were added in 2025, I've used 2025-2026 as copyright
years.
projects / thirdparty / binutils-gdb.git / log
