H.J. Lu [Thu, 18 Jun 2026 11:57:20 +0000 (19:57 +0800)]
ld: Use 0x10000 as absolute symbol value in PR ld/25754 tests
PR ld/25754 tests verify that relocations against absolute symbol are
properly handled, using 42 as the absolute symbol value. But GCC 17
treats 42 as the impossible symbol address, which is the absolute symbol
value and optimize out the symbol address check:
Tom de Vries [Thu, 18 Jun 2026 20:06:50 +0000 (22:06 +0200)]
[gdb] Fix new blank line at EOF in a few xml files
Fix this:
...
gdb/features/sparc/sparc32-cp0.xml:19: new blank line at EOF.
gdb/features/sparc/sparc64-cp0.xml:17: new blank line at EOF.
gdb/features/sparc/sparc64-fpu.xml:60: new blank line at EOF.
gdb/features/s390-core64.xml:45: new blank line at EOF.
gdb/features/sparc/sparc32-fpu.xml:43: new blank line at EOF.
gdb/features/aarch64-pauth.xml:13: new blank line at EOF.
gdb/features/library-list-aix.dtd:18: new blank line at EOF.
...
I re-ran "make clean-cfiles cfiles" in gdb/features, no changes.
Tom de Vries [Thu, 18 Jun 2026 20:06:50 +0000 (22:06 +0200)]
[gdb] Fix new blank line at EOF in a few scripts
Fix this:
...
gdb/contrib/ari/gdb_ari.sh:1216: new blank line at EOF.
gdb/contrib/ari/create-web-ari-in-src.sh:82: new blank line at EOF.
gdb/config/djgpp/djcheck.sh:48: new blank line at EOF.
...
Tom de Vries [Thu, 18 Jun 2026 20:06:50 +0000 (22:06 +0200)]
[gdb] Fix leftover conflict marker in gdb/config/djgpp/README
For gdb/config/djgpp/README, we have:
...
gdb/config/djgpp/README:6: leftover conflict marker
...
This is a false positive, this is just some text formatting using '=':
...
General
=======
...
whose length happens to match the default value of git attribute
conflict-marker-size: 7.
Fix this by setting the conflict-marker-size to 80.
Tom de Vries [Thu, 18 Jun 2026 20:06:50 +0000 (22:06 +0200)]
[gdb] Increase clean range in check-whitespace-pre-commit.py
The list of files completely checked by check-whitespace-pre-commit.py is
determined by this regexp:
...
re_clean = re.compile(
"(^(gdb/testsuite/|gdbsupport/|gdbserver/)|[.](m4|ac|def|[chly])$|NEWS)"
)
...
Turn this around, and add a todo list of files not completely whitespace clean
yet, enabling complete checking for all other files.
Tom Tromey [Tue, 2 Jun 2026 17:27:15 +0000 (11:27 -0600)]
Print command trace to gdb_stdlog
I recently wanted to enable some gdb logging when running the internal
AdaCore test suite. To do this nicely, I enable debug-redirect early
in the test, so that the logging output does not affect the test
results.
I also wanted to the log the commands, to correlate what I see in the
debug log with what I see in the ordinary test suite log file (which
is basically like our own gdb.log).
However, I found that "set trace-commands on" will log to stdout, not
stdlog. This patch changes this to log to the log file instead.
Tom de Vries [Thu, 18 Jun 2026 15:53:43 +0000 (17:53 +0200)]
[gdb] Ignore codespell warnings about wrong encodings
With "pre-commit run codespell --all-files -v" we get warnings:
...
$ pre-commit run codespell --all-files -v
codespell................................................................Passed
- hook id: codespell
- duration: 1.52s
WARNING: Cannot decode file using encoding "utf-8": \
gdb/testsuite/gdb.ada/non-ascii-latin-1/pack.adb
WARNING: Trying next encoding "iso-8859-1"
...
Disable these by setting quiet-level in gdb/pyproject.toml.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34291
Tom de Vries [Thu, 18 Jun 2026 15:21:59 +0000 (17:21 +0200)]
[gdb/contrib] Rename license-check-new-files.sh to .py
Rename gdb/contrib/license-check-new-files.sh to
gdb/contrib/license-check-new-files.py.
Fix the resulting flake8 fallout:
...
gdb/contrib/license-check-new-files.py:58:5: E722 do not use bare 'except'
gdb/contrib/license-check-new-files.py:106:9: E722 do not use bare 'except'
...
Alan Modra [Thu, 18 Jun 2026 05:41:53 +0000 (15:11 +0930)]
buffer overflow in fetch_indexed_addr
oss-fuzz found another case where sanity checks weren't good enough.
* dwarf.c (fetch_indexed_addr): Avoid integer overflow when
sanity checking field offset
(fetch_indexed_offset): Similarly. Don't bother with "too small"
warning, which will be covered by field offset check. Warn
about base and index rather than possibly overflowed calculation.
Alan Modra [Thu, 18 Jun 2026 02:17:05 +0000 (11:47 +0930)]
PR 29655 test: xfail more targets
Apparently some libraries (Qt5 is called out in PR 29655) want to know
if one of their functions has been overridden, and do so by comparing
the address of the function with the address of a local hidden alias.
This is a bug in every such library that tries that trick, because if
the main program is non-PIC and calls the function in question then
the globally visible address of the function is set to the PLT call
stub code for that function in the main executable. This will happen
even when there is no real overriding of the function.
On the other hand if the main executable is PIC then there should be
no need to define function addresses on PLT call stub code, but some
linker target support still does so. This is a minor bug in the
linker as it results in more work in ld.so and sligntly slower
startup. However, I don't think it is an important issue if target
maintainers can't fix the problem.
* testsuite/ld-elf/shared.exp (pr29655): xfail more targets.
Alan Modra [Wed, 17 Jun 2026 23:53:00 +0000 (09:23 +0930)]
elflink.c: remove unnecessary casts
I noticed when going through elflink.c looking for places where memory
allocation function return values weren't checked, that many places
still have the now unnecessary casts from K&R days. This patch
removes them, and tidies some places that don't need to use a variable
to pass the size.
Alan Modra [Wed, 17 Jun 2026 23:52:32 +0000 (09:22 +0930)]
buffer_read_memory hardening
What drew my attention here was wondering if division of the buffer
length or the requested length by octets_per_byte could result in
trucation and thus an incomplete check for possible buffer overflow.
Rather than convincing myself that this couldn't happen, I decided to
rewrite the checks in a way that avoids the possibility of truncation,
and avoids any addition overflows too.
Tom de Vries [Wed, 17 Jun 2026 19:40:03 +0000 (21:40 +0200)]
[pre-commit] Reorganize .pre-commit-config.yaml
Reorganize .pre-commit-config.yaml:
- unify indentation
- move local hooks to last
- add empty lines and header comments to make file more readable
- move detailed file selection comment from flake8 settings to
"Python hooks" since it's valid for all python hooks, and
explain why the types_or setting is needed.
- use anchors to avoid repetition
Tom de Vries [Wed, 17 Jun 2026 19:40:03 +0000 (21:40 +0200)]
[pre-commit] Remove stages setting for two hooks
Some hooks have a setting:
...
stages: [pre-commit]
...
but since that's identical to the default setting:
...
default_stages: [pre-commit]
...
we can just remove those.
Joel Brobecker [Wed, 17 Jun 2026 17:30:24 +0000 (10:30 -0700)]
gdb/MAINTAINERS: Document the change of release managers
I am stepping down as GDB Release manager. Andrew Burgess and
Simon Marchi have both kindly volunteered to take on this role.
This commit updates the gdb/MAINTAINERS file accordingly.
Lancelot SIX [Wed, 3 Jun 2026 14:34:09 +0000 (15:34 +0100)]
gdb/amd-dbgapi-target: drop reference to amd_dbgapi_address_class_id_t
The rocm-dbgapi header defines a few handle types, and the
gdb/amd-dbgapi-target.h defines some generic helpers for them
(operator== and operator!=). Nothing in GDB uses
amd_dbgapi_address_class_id_t, and this type will be removed from the
library.
Since this is not used and will be removed in the future, remove the
definition of operator== / operator!= for amd_dbgapi_address_class_id_t.
Build tested, no visible user impact expected.
Change-Id: If4c343120633b8d5b933a5ac7e722a2ed01f8b3c Approved-By: Pedro Alves <pedro@palves.net>
Tom de Vries [Tue, 16 Jun 2026 22:36:17 +0000 (00:36 +0200)]
[pre-commit] Use pass_filenames=false for pre-commit-setup
I came across pre-commit setting pass_filenames, and realized we can use it
for the pre-commit-setup hook.
It saves about half a second for an all-files run. Before:
...
$ ( time pre-commit run pre-commit-setup --all-files ) 2>&1 | grep real
real 0m1,136s
...
and after:
...
$ ( time pre-commit run pre-commit-setup --all-files ) 2>&1 | grep real
real 0m0,635s
...
Tom de Vries [Tue, 16 Jun 2026 18:34:14 +0000 (20:34 +0200)]
[pre-commit] Stop using deprecated language script
In v4.4.0, pre-commit renamed language script to unsupported_script.
The rename was done to stress that pre-commit doesn't provide an environment
for the script to run in [1].
The language script is now a deprecated alias for unsupported_script, and the
plan seems to be to initially produce a deprecation warning, and eventually
remove support for the alias completely.
Start using the new name: unsupported_script.
Furthermore, the check-include-guards hook uses language python, and indeed it
uses a python script, but it doesn't really need a virtual environment. It
imports modules fnmatch, re, sys and typing, all of which are available in
python 3.10 and later, which is the environment pre-commit itself requires
(because we require pre-commit v4.5.1 or later, and pre-commit requires python
3.10 since v4.4.0). So while we're at it, use unsupported_script for this
hook as well, reducing the amount of environments pre-commit has to manage.
Tested using "pre-commit run --all-files" with python 3.10, as well as 3.13.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
[1] https://github.com/pre-commit/pre-commit/pull/3577
Wilco Dijkstra [Tue, 26 May 2026 18:37:58 +0000 (18:37 +0000)]
AArch64 gas: Block section relative symbols in GOT relocations [PR30788]
By default, GAS changes GOT relocations of local symbols into section relative.
This is incorrect since GOT relocations do not support offsets. Update
aarch64_fix_adjustable() to explicitly disallow this for GOT relocations.
This fixes PR30788.
Tom de Vries [Mon, 15 Jun 2026 08:28:32 +0000 (10:28 +0200)]
[gdb] Fix flake8 warning in gdb.python/py-inf-exited-at-exit.py
With current trunk we have:
...
$ pre-commit run flake8 --all-files
flake8..................................................................Failed
- hook id: flake8
- exit code: 1
gdb.python/py-inf-exited-at-exit.py:22:1: F821 undefined name 'gdb'
...
Tom de Vries [Mon, 15 Jun 2026 08:28:32 +0000 (10:28 +0200)]
[gdb] Fix file mode of gdb/microblaze-linux-nat.c
With current trunk we have:
...
$ pre-commit run check-file-mode --all-files
check-file-mode.........................................................Failed
- hook id: check-file-mode
- exit code: 1
Tom de Vries [Mon, 15 Jun 2026 08:16:45 +0000 (10:16 +0200)]
[pre-commit] Add file mode check
Claude Code mentioned in a review that a source file was marked executable.
I've submitted a patch to fix this [1].
Detect this problem using pre-commit to prevent it from re-occurring.
The state before commit 15363a3be77 ("[gdb] Drop executable mode in some
files") gives us (abbreviated output using "..."):
...
$ pre-commit run check-file-mode --all-files
check-file-mode.........................................................Failed
- hook id: check-file-mode
- exit code: 1
gdb: refactor core_target ::close and ::detach functions
it was observed that the Python 'exited' event was no longer being
emitted when debugging a core file, and then exiting GDB.
The problem is that, when GDB is exiting we eventually end up in
quit_force (in top.c), which calls kill_or_detach for every inferior.
In kill_or_detach we call either target_detach or target_kill, but
only for non-core file targets. For core file targets, neither of
these is called and kill_or_detach does nothing of interest.
After the call to kill_or_detach, we call inferior::pop_all_targets,
which calls inferior::pop_all_targets_above the dummy_stratum target,
which means popping all targets.
In inferior::pop_all_targets_above (in inferior.c), we call
switch_to_inferior_no_thread, which ensures the correct inferior is
selected, but makes it so that no thread is selected. Switching to no
thread sets inferior_ptid to null_ptid.
Now popping the core_target calls core_target::close, and within
core_target::close we currently check inferior_ptid in order to
determine if exit_core_file_inferior has already been called or not.
We only call exit_core_file_inferior if inferior_ptid is not
null_ptid, so in this case we will not call exit_core_file_inferior.
The only other place that exit_core_file_inferior can be called from
is core_target::detach, but remember we specifically avoided calling
target_detach earlier in kill_or_detach. This means that
exit_core_file_inferior ends up never being called.
It is exit_core_file_inferior that calls exit_inferior, and it is from
here that the Python 'exited' event is emitted.
I don't see any reason why kill_or_detach couldn't call target_detach
for a core file target, but I don't propose making that change in this
commit.
The check against inferior_ptid in core_target::close is clearly
incorrect, checking this requires that a suitable thread within the
inferior be selected, and that is not really a requirement for closing
a core_target. Instead, we can just check the inferior::pid field.
When we open a core_target we always set inferior::pid, even if we
just assign a fake CORELOW_PID value, so checking inferior::pid
against zero will tell us if the inferior has already been exited.
Fixing this check is enough to resolve the reported bug and ensure
that the 'exited' event is always emitted, which is why I don't
propose changing kill_or_detach in this commit.
An assert in core_target::exit_core_file_inferior has to go too for
the same reason, the assert is checking that a thread is currently
selected, and as discussed above, this is not always the case.
There's a new test which checks that the 'exited' event is emitted for
a core file debug session, a native debug session where the inferior
is started by GDB, and a native debug session where GDB attaches to an
already running inferior.
Only the core file case was broken before this commit, but more
testing is always a good thing.
Reviewed-By: Lancelot Six <lancelot.six@amd.com> Approved-By: Pedro Alves <pedro@palves.net>
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>
projects / thirdparty / binutils-gdb.git / log
