blob: 2cbe0e13ba4099d6cdc928026a57d9ee4120be4d [file] [log] [blame]
# Copyright 2019-2021 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
# 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 <>.
# This test covers a case where SIGSTOP has been configured to be
# passed to the target with GDB's 'handle' command, and then a
# multi-threaded inferior encounters an event that causes all threads
# to be stopped.
# The problem that (used) to exist was that GDB would see the SIGSTOP,
# but decide to ignore the signal based on the handle table.
if {[prepare_for_testing "failed to prepare" \
"${testfile}" "${srcfile}" {debug pthreads}]} {
return -1
if ![runto_main] then {
return 0
# Have SIGSTOP sent to the inferior.
gdb_test "handle SIGSTOP nostop noprint pass" \
[multi_line \
"Signal\[ \t\]+Stop\[ \t\]+Print\[ \t\]+Pass to program\[ \t\]+Description" \
"SIGSTOP\[ \t\]+No\[ \t\]+No\[ \t\]+Yes\[ \t\]+Stopped \\(signal\\)"]
# Create a breakpoint, and when we hit it automatically finish the
# current frame.
gdb_breakpoint breakpt
# When the bug triggers this continue never completes. GDB hits the
# breakpoint in thread 1, and then tries to stop the second thread by
# sending it SIGSTOP. GDB sees the SIGSTOP arrive in thread 2 but
# incorrect decides to pass the SIGSTOP to the thread rather than
# bringing the thread to a stop.
gdb_continue_to_breakpoint breakpt