binutils-gdb/gdb/testsuite/gdb.threads/pending-step.exp
Joel Brobecker 42a4f53d2b Update copyright year range in all GDB files.
This commit applies all changes made after running the gdb/copyright.py
script.

Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.

gdb/ChangeLog:

	Update copyright year range in all GDB files.
2019-01-01 10:01:51 +04:00

89 lines
2.9 KiB
Plaintext

# Copyright (C) 2009-2019 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 that a resume cancels a previously unfinished or unreported
# single-step correctly.
#
# The test consists of several threads all running the same loop.
# There is a breakpoint set in the loop, hence all threads may hit it.
# The test then issues several "next" commands in a loop.
#
# scheduler-locking must be set to the default of "off".
#
# Here's what would happen in gdbserver:
#
# 1) We issue a "continue", and wait until a thread hits the
# breakpoint. Could be any thread, but assume thread 1 hits it.
#
# 2) We issue a "next" --- this single-steps thread 1, and resumes all
# other threads.
#
# 3) thread 2, due to scheduler-locking off, hits the breakpoint.
# gdbserver stops all other threads by sending them SIGSTOPs.
#
# 4) While being stopped in step 3, thread 1 reports a SIGTRAP, that
# corresponds to the finished single-step of step 2. gdbserver
# leaves the SIGTRAP pending to report later.
#
# 5) We issue another "next" --- this requests thread 2 to
# single-step, and all other threads to continue, including thread
# 1. Before resuming any thread, gdbserver notices that it
# remembers from step 4 a pending SIGTRAP to report for thread 1,
# so reports it now.
#
# 6) From GDB's perpective, this SIGTRAP can't represent a finished
# single-step, since thread 1 was not single-stepping (it was
# continued in step 5). Neither does this SIGTRAP correspond to a
# breakpoint hit. GDB reports to the user a spurious SIGTRAP.
standard_testfile
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable debug] != "" } {
return -1
}
clean_restart ${binfile}
if ![runto_main] then {
fail "can't run to main"
return 0
}
gdb_breakpoint [gdb_get_line_number "insert breakpoint here"]
gdb_continue_to_breakpoint "continue to first breakpoint hit"
set test "next in multiple threads with breakpoints"
set iterations 20
set ok 0
for {set i 0} {$i < $iterations} {incr i} {
set ok 0
gdb_test_multiple "next" "$test" {
-re " received signal SIGTRAP.*$gdb_prompt $" {
fail "$test (spurious SIGTRAP)"
}
-re "$gdb_prompt $" {
set ok 1
}
}
if { $ok == 0 } {
break
}
}
if { $ok } {
pass "$test"
}