gdb/testsuite: Add runtime-core-attached test by amd-bfilipov · Pull Request #216 · ROCm/ROCgdb

amd-bfilipov · 2026-07-16T14:32:42Z

Test core dump generation while program runs under GDB. With the fix for core dump collection during debugging, verify that running under GDB in batch mode with signal passthrough generates both host and GPU cores, which can be merged and loaded.

What we're testing:

Run a HIP program under GDB
Configure GDB to pass signals through (not stop on them)
Program crashes with GPU fault
ROCm runtime generates core dumps even though GDB is attached
Verify GDB can load those cores and see GPU threads

Uses batch mode: -ex 'handle SIGABRT/SIGSEGV nostop pass' -ex 'run' This allows GDB to catch faults but pass them to runtime/kernel.

Motivation

Tests the new capability from ROCm/rocm-systems#6811 that enables core dump generation even when a debugger is
attached

Technical Details

Runs test program under GDB in batch mode with signal passthrough configuration
Verifies both host (core.*) and GPU (core.*.gpu) cores are generated
Merges cores using coremerge and validates they can be loaded in GDB
Uses system command to inherit test environment (LD_LIBRARY_PATH)
Tests pagefault and abort scenarios

lancesix

Some preliminary comments. Will do a more in depth review later.

lumachad

Could we please have a better description of what we're trying to test here? The "test core dump while gdb is attached" sounded to me like we were controlling rocgdb when generating the core file, but it sounds like what we want is for some unrelated process to be generating a core file while we test something else in the runtime.

Is that the case? If so, should this be a ROCR test instead?

aktemur · 2026-07-30T11:56:49Z

+    gdb_test "handle SIGABRT nostop pass" ".*"
+    gdb_test "handle SIGSEGV nostop pass" ".*"
+    gdb_test_no_output "set cwd $coredir"
+    gdb_test "set args $fault" ".*"


gdb_test_no_output

Done. Changed to gdb_test_no_output "set args $fault" on line 53.

aktemur · 2026-07-30T11:57:31Z

+    # a while for large core dumps.
+    with_timeout_factor 3 {
+	gdb_test_multiple "" "wait for program exit" {
+	    -re "Program terminated with signal" {


Also -wrap?

Multiple messages arrive before the prompt (both "Program terminated" and "The program no longer exists"), so
-wrap on each pattern causes race conditions; using exp_continue for messages and matching the final prompt
directly works correctly.

aktemur · 2026-07-30T11:58:21Z

+    with_timeout_factor 3 {
+	gdb_test_multiple "" "wait for program exit" {
+	    -re "Program terminated with signal" {
+		pass "program crashed"


Let's please use $gdb_test_name. Also in the occurrences below.

aktemur · 2026-07-30T12:11:20Z

+    gdb_test "target core $merged_core" \
+	[multi_line \
+	    ".*" \
+	    "Core was generated by .*" \


I feel uneasy about .*'s in such cases, because they can also match newline. Can we use \[\r\n\]* instead. Also in the line below.

The pattern (lines 120-124) follows the established pattern from runtime-core.exp for matching core file loading output. The leading .* on line 121 is necessary to skip the library loading messages that precede "Core was generated by". The trailing .* patterns allow matching variable content (command arguments, signal details, wave coordinates). The multi_line structure with these patterns has been proven to work correctly in the sibling test.

lancesix · 2026-08-03T12:25:52Z

+require allow_rocm_core_tests
+require allow_hip_tests
+
+standard_testfile runtime-core.cpp


We usually try to have a 1:1 mapping between .ccp and .exp. Either what is tested here fits in runtime-core.exp, or this test should have its own test program.

Sure, added runtime-core-attached.cpp

lancesix · 2026-08-03T12:32:20Z

+    # Check that ulimit allows core dumps.  The test environment must
+    # have ulimit -c set to unlimited before running this test.
+    set ulimit_value [exec sh -c "ulimit -c"]
+    if {$ulimit_value != "unlimited"} {


I am not sure checking ulimit that way is sufficient. For example, if building GDB with ASAN, the ASAN runtime implicitly turns ulimit to 0 (the ASAN has a heavy impact on core size otherwise):

$ ulimit -c unlimited $ ASAN_OPTIONS=detect_leaks=0 ./gdb/gdb -data-directory ./gdb/data-directory -ex "shell ulimit -c" -q -batch 0

I've removed the check, since runtime-core.exp does not check for it either.

Test core dump generation while program runs under GDB. What we're testing: 1. Run a HIP program under GDB 2. Configure GDB to pass signals through (not stop on them) 3. Program crashes with GPU fault 4. ROCm runtime generates core dumps even though GDB is attached 5. Verify GDB can load those cores and see GPU threads Uses batch mode: -ex 'handle SIGABRT/SIGSEGV nostop pass' -ex 'run' This allows GDB to catch faults but pass them to runtime/kernel.

lancesix · 2026-08-20T10:32:50Z

+#include <stdlib.h>
+#include "gdb_watchdog.h"
+
+#define CHECK(cmd)                                                           \


Please use the version from rocm-test-utils.h.

lancesix · 2026-08-20T10:34:35Z

+    return -1
+}
+
+proc do_attached_test { fault } {


attached_coredump_test?

lancesix · 2026-08-20T10:38:02Z

+		return
+	    }
+	}
+    }


This gdb_test_multiple seems much.

The "timeout" should be handled by default by gdb_test_multiple (or gdb_test), and the other cases only use exp_continue. All this matches is that we got the prompt back, which we could as well do with gdb_test "run" "The program no longer exists", couldn't we?.

lumachad

Automated comments:

lumachad · 2026-08-21T08:52:34Z

+{
+  memfault,
+  abort
+};


abort as an enum member shadows the global ::abort() called by abort_kernel a few lines above. This compiles in C++ because the enum member is only in scope where the type is used as testcase_t::abort, but it is confusing and fragile. Rename it, e.g. kabort or do_abort, as is idiomatic in GDB test sources — see runtime-core.cpp which has the same pattern and the same risk.

lumachad · 2026-08-21T08:52:34Z

+pagefault_kernel (int *out)
+{
+  int local = 42;
+  *out = 8;


int local = 42 is unused by the test — unlike runtime-core.exp, this test never runs p local. Either remove it, or add a comment explaining it is intentionally left for future frame-variable checks (as runtime-core.cpp uses it). Same applies to abort_kernel (line 61) and aux_kernel (line 73).

lumachad · 2026-08-21T08:52:34Z

+
+    clean_restart $::testfile
+    gdb_test "handle SIGABRT nostop pass" ".*"
+    gdb_test "handle SIGSEGV nostop pass" ".*"


".*" as the expected pattern records no meaningful output check and produces a generic pass/fail. Use gdb_test_no_output if no output check is intended, or supply a real pattern such as "Signal.*SIGABRT.*No.*Yes.*" so the signal-handler table is at least spot-checked. Same for the SIGSEGV handle command on the next line.

lumachad · 2026-08-21T08:52:34Z

+    set hostcore [lindex $hostcore_list 0]
+
+    pass "generated both cores while gdb attached"
+


This pass fires before coremerge is invoked (line 100) and before gdb_assert checks that the merged core exists (line 101). A coremerge failure will still leave this pass on record. Move the pass to after the gdb_assert, or fold it into the assert message.

lumachad · 2026-08-21T08:52:34Z

+    set coremerge [gdb_find_coremerge]
+    set merged_core "$coredir/merged-$fault.core"
+    remote_exec build "$coremerge $merged_core $hostcore $gpucore"
+


The return value of remote_exec build "$coremerge ..." is ignored. If coremerge is not found or exits non-zero, the subsequent gdb_assert fires with a confusing message. Follow the pattern in rocm.exp:599-604: check [remote_file build exists $merged_core] immediately and emit a warning with the coremerge stderr if it is absent, then return early.

amd-bfilipov requested a review from a team as a code owner July 16, 2026 14:32

github-actions Bot assigned aktemur Jul 16, 2026

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 2 times, most recently from 6262869 to 3d062bb Compare July 16, 2026 14:42

lancesix reviewed Jul 16, 2026

View reviewed changes

Comment thread gdb/testsuite/gdb.rocm/runtime-core-attached.exp Outdated

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 2 times, most recently from 16e1248 to 6fa15be Compare July 16, 2026 15:35

aktemur reviewed Jul 17, 2026

View reviewed changes

aktemur assigned amd-bfilipov and unassigned aktemur Jul 17, 2026

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 3 times, most recently from 51b440f to 5108ffd Compare July 17, 2026 18:40

lumachad reviewed Jul 20, 2026

View reviewed changes

Comment thread gdb/testsuite/gdb.rocm/runtime-core-attached.exp Outdated

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 3 times, most recently from be3797f to 3e11ade Compare July 21, 2026 15:55

aktemur reviewed Jul 23, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 3 times, most recently from 531654b to 2b99b98 Compare July 27, 2026 13:52

amd-bfilipov requested a review from aktemur July 27, 2026 14:06

aktemur reviewed Jul 30, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 2 times, most recently from 37620ba to 5703c12 Compare August 3, 2026 10:58

lancesix reviewed Aug 3, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch from 5703c12 to 6fc6cb4 Compare August 3, 2026 12:41

amd-bfilipov requested review from aktemur and lancesix August 3, 2026 12:51

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch from 6fc6cb4 to f5ecd1e Compare August 4, 2026 10:01

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 4 times, most recently from b35e2fd to aad3169 Compare August 4, 2026 10:16

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch from aad3169 to 6dd0052 Compare August 4, 2026 11:37

lancesix reviewed Aug 20, 2026

View reviewed changes

lumachad reviewed Aug 21, 2026

View reviewed changes

		set hostcore [lindex $hostcore_list 0]

		pass "generated both cores while gdb attached"

Uh oh!

Conversation

amd-bfilipov commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Technical Details

Uh oh!

lancesix left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lumachad left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lumachad left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amd-bfilipov commented Jul 16, 2026 •

edited

Loading