[PATCH v2 47/47] testsuite, sycl: test canceling a stepping flow

Tankut Baris Aktemur
2024-12-13T16:39:01Z

If there exists a pending event for stepping in a range, this means
the stepping flow was broken because of another event, such as another
thread hitting a breakpoint. The stepping flow in this case is
canceled. Test it.
---
gdb/testsuite/gdb.sycl/step-canceled.exp | 86 ++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)

diff --git a/gdb/testsuite/gdb.sycl/step-canceled.exp b/gdb/testsuite/gdb.sycl/step-canceled.exp
new file mode 100644
index 0000000000000000000000000000000000000000..0b03dd11495e297fca0684b5c0334e138a05d91b
--- /dev/null
+++ b/gdb/testsuite/gdb.sycl/step-canceled.exp
@@ -0,0 +1,86 @@
+# Copyright 2023-2024 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+# Test the target's handling of stepping.
+#
+# In this scenario we start stepping for a thread and resume the
+# others. There is a breakpoint close to the current PC. We expect
+# other threads to hit that BP before the current thread finishes
+# stepping its range. Hence, the step flow would be broken and
+# canceled. We should be able to resume the thread without problems.
+
+load_lib sycl.exp
+
+standard_testfile parallel-for-1D.cpp
+
+set sycl_device_list [init_sycl_devices_list]
+if {[llength $sycl_device_list] == 0} {
+ unsupported "target does not support SYCL"
+ return 0
+}
+
+if {[build_executable "failed to compile $srcfile" \
+ "${binfile}" $srcfile {sycl debug}]} {
+ return -1
+}
+
+foreach device $sycl_device_list {
+ sycl_with_intelgt_lock $device {
+ clean_restart "${binfile}"
+
+ if {![sycl_start $device]} {
+ continue
+ }
+
+ set first_line [gdb_get_line_number "kernel-first-line"]
+ set next_line [expr $first_line + 1]
+ gdb_breakpoint $first_line {temporary}
+
+ # Explicitly control the scheduler-locking setting.
+ gdb_test_no_output "set scheduler-locking off"
+
+ gdb_continue_to_breakpoint "hit the first line" \
+ ".*$srcfile:$first_line.*"
+ gdb_breakpoint $next_line
+
+ set first_thread [get_current_thread "first bp line"]
+
+ # Now only the second BP is there. The "step" command will
+ # start a stepping flow for the first thread whereas it will
+ # resume the others. We expect the others to hit the BP,
+ # because it is very close to our current PC, but of course
+ # there is a slight chance that this will not happen and the
+ # first thread will win the race.
+ gdb_test "step" "$srcfile:$next_line.*" "start stepping"
+ set second_thread [get_current_thread "second bp line"]
+
+ if {$first_thread eq $second_thread} {
+ # There was really a very very low chance of this happening.
+ untested "test condition could not be satisfied"
+ continue
+ }
+
+ # Resume the first thread only. It should hit the second BP
+ # normally.
+ gdb_test_no_output "set scheduler-locking on"
+ gdb_test "thread $first_thread" ".*" "switch to the first thread"
+ gdb_continue_to_breakpoint "resume the thread" \
+ ".*$srcfile:$next_line.*"
+
+ set curr_thread [get_current_thread "second bp line again"]
+ gdb_assert {"$curr_thread" eq "$first_thread"} \
+ "sanity-check the current thread"
+ }
+}