[2026-06-16] Merge remote-tracking branch 'origin/master' into amd-staging#175
Merged
Conversation
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
This patch adds amd-dbgapi-mingw-hdep.c which provides the implementations for all the host specific interactions with dbgapi on MinGW. Co-Authored-By: Pedro Alves <pedro@palves.net> Change-Id: Ie244f2606b1e0af8f85b9113c3d93585eda893ed
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
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. Change-Id: Ib54d9e6998cf9bfc18dcb5e76d31a9deb0458da4
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 Change-Id: Ibda1540a602b62c26a5b218d930402eccc3ba98f
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. Change-Id: I9a1af298b0e4f62f38b5c4b14787d7e40a2b5e2c
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. Change-Id: I49ccfdbbe4be4445172476e7dd4e06142c8a672e
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. Change-Id: I9908aef0cea3eaec8134f05e347702baf753d10c
…gwin This adds a new "win32" option to gdb_compile that lets us compile native Windows programs when testing Cygwin. Will be used in a following patch. The testsuite tries to find the compiler to use automatically. You can also explicitly set it with WIN32_CC_FOR_TARGET. Change-Id: I86e954494cf7f88164cdf1c9127be46d5437986f
Move the exit status logic added by commit 559e7e5 ("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. Change-Id: I4bf08c6beff0d1688064a81d49bbdd615643735e
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
This commit fixes a couple issues in gdb.python/py-events.exp for Cygwin and MinGW: 1) - GDB prints Windows thread IDs in hex: (gdb) thread [Current thread is 1 (Thread 9528.0xa9c)] The current code assumes decimal, so we only (incorrectly) extract the "0" after the dot. 2) - Thread and process ID number spaces are different. The current code assumes that the extracted thread ID is the same number as the extracted process ID, which is not true on Windows. Also tested on x86_64-unknown-linux-gnu. Change-Id: Iebcc07c3ad0845b548334c0d5177b3ab9e9350cf
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. Tested on x86_64-unknown-linux-gnu. Change-Id: I21ee8af7b52653c6fdff9b4c1596cdde3cfe751a
…erior" 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. Also tested on x86_64-unknown-linux-gnu. Change-Id: If6ff482ceb011d9afe5ed40ef7e4e2f2cad8cae8
Coverage testing showed that there were no existing tests of the Ada "in" operator. This patch adds tests for this. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34041
Add checks in a couple of places for a non-NULL return. While we're at it, don't use sprintf to concatenate two strings. * elflink.c (bfd_elf_link_record_dynamic_symbol): Check than bfd_malloc returns non-NULL. (get_dynamic_reloc_section_name): Similarly check bfd_alloc. Replace sprintf with two memcpys. Remove old_name NULL check.
Yet another case where a fuzzed object file triggers a crash in the vms-alpha support. * vms-alpha.c (image_write_section): Don't segfault on NULL image_section.
Convert gdb.dwarf2/dw2-strp.exp to dwarf assembly using gdb/contrib/dwarf-to-dwarf-assembler.py. Tested on x86_64-linux. Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
This fixes an issue that was reported here: https://inbox.sourceware.org/gdb-patches/v3x4md2dg6rflq35ymzwrmmqf5uaem5exrnlbsp5dmhph2vihy@lq22ncu774yu After commit: commit 3780b99 Date: Fri Mar 27 11:29:07 2026 +0000 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>
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 15363a3 ("[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 100755 ... gdb/testsuite/gdb.base/jump_multiple_objfiles.h 100755 ... gdb/testsuite/gdb.fortran/nested-funcs.f90 100755 ... gdb/testsuite/gdb.fortran/oop_extend_type.f90 100755 ... gdb/amd64-tdep.c 100755 ... gdb/testsuite/lib/compiler.cc 100755 ... gdb/testsuite/gdb.fortran/nested-funcs.exp 100755 ... gdb/testsuite/gdb.fortran/vla-type.f90 100755 ... gdb/testsuite/gdb.arch/amd64-lam.c 100755 ... gdb/testsuite/gdb.base/jump_multiple_objfiles.exp 100755 ... gdb/testsuite/gdb.testsuite/gdb_test_multiple-lbl.gdb 100755 ... gdb/testsuite/gdb.btrace/exception.exp 100755 ... gdb/testsuite/gdb.fortran/vla-type.exp 100755 ... gdb/testsuite/gdb.base/jump_multiple_objfiles.c 100755 ... gdb/testsuite/gdb.base/jump_multiple_objfiles-foo.c 100755 ... gdb/testsuite/gdb.fortran/oop_extend_type.exp 100755 ... gdb/testsuite/gdb.fortran/print_type.exp ... Shell-checked new script gdb/contrib/check-file-mode.sh. Changes in v2: - make sure git failure makes the script fail - make case statement more readable Versions: - v1 https://sourceware.org/pipermail/gdb-patches/2026-June/227791.html [1] https://sourceware.org/pipermail/gdb-patches/2026-June/227780.html
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 100755 ... gdb/microblaze-linux-nat.c ... Fix this using chmod -x.
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' ... Fix this by adding the missing import.
For each word in codespell-ignore-words.txt, add a line briefly describing its meaning.
Add more words to ignore in codespell-ignore-words.txt.
Fix typos in the gdb dir.
Fix codespell false positives in the gdb dir, by ignoring them.
Fix codespell false positive in gdb dir, by string splitting.
Fix codespell false positives in gdb dir, by renaming identifiers and splitting words.
Include the files in the gdb dir in the codespell pre-commit check.
Simplify the codespell configuration in .pre-commit-config.yaml by moving the file selection to gdb/pyproject.toml.
Result of: ... $ codespell --toml gdb/pyproject.toml -w -i3 gdb/microblaze-linux-nat.c /* Transfering floating-point registers between GDB, inferiors and cores. Transfering ==> Transferring (Y/n) FIXED: gdb/microblaze-linux-nat.c gdb/microblaze-linux-nat.c:97: Transfering ==> Transferring ...
A recent codespell cleanup in gdb/testsuite made some files and a dir in the codespell skip list codespell-clean. Drop these from the skip list.
Replace all dirs in the codespell skip list with the actual files that are not codespell-clean. At this point, there's just ~60 of them. This enables codespell checking for yet more files.
Add endianity to codespell-ignore-words.txt, as per this review comment [1]. [1] https://sourceware.org/pipermail/gdb-patches/2025-December/223137.html
Sync recent changes to libiberty. include/ChangeLog: * libiberty.h (expandargstr): Declare. libiberty/ChangeLog: * argv.c (expandargstr): New function. Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
2adde52 to
f6d6ffe
Compare
Collaborator
|
The set_unbuffered_mode_saved.o changes have a problem. To see it easily, you can force that code path to run on linux too with this hack: and with that, we get: "file basename" doesn't exist. It's spelled "file tail" instead. $ rlwrap tclsh But then I don't understand why we'd need to extract the basename, since gdb_saved_set_unbuffered_mode_obj_name is always a basename, never a full path. So I think not calling "file tail" or anything at all would work. Like: That works for me on Linux with the hack above. Not sure if I missed something, though. While at it, typo in commit log: becauso => because |
f6d6ffe to
1fd21d1
Compare
Collaborator
Author
|
Fixed, applied the change as suggested. |
1fd21d1 to
5339de1
Compare
Collaborator
Author
|
I had to rebase the merge as well, here is the delta between rebase and fixed patch: |
palves
approved these changes
Jun 23, 2026
Handle conflicts introduced by recent upstream changes. Conflicting upstream changes are: - c4aa08d gdb/amd-dbgapi-target: Move Linux code to amd-dbagapi-posix-hdep.c - f67ddc1 gdb/amd-dbgapi-target: Update xfer_partial to always use dbgapi - c04f1f5 gdb/testsuite: Add mechanism to compile Windows native programs on Cygwin - 2b5689d [gdb/contrib] Describe words in codespell-ignore-words.txt Most changes were trivial. The main notable changes are in gdb/testsuite/lib/gdb.exp, because of downstream change 27f8b77 "HIP and set_unbuffered_mode_saved.o". This merge commit also corrects one typo as codespell have been enabled for the gdb directory by 664cc2d [pre-commit] "Include gdb in codespell check". Change-Id: If845e1d08c00f9e758f71d9b40e836a162c6c25a
5339de1 to
0e58174
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Handle conflicts introduced by recent upstream changes. Conflicting
upstream changes are:
Most changes were trivial. The main notable changes are in
gdb/testsuite/lib/gdb.exp, becauso of downstream change 27f8b77 "HIP
and set_unbuffered_mode_saved.o".
This merge commit also corrects one typo as codespell have been enabled
for the gdb directory by 664cc2d [pre-commit] "Include gdb in
codespell check".