Files
binutils-gdb/gdb/testsuite/gdb.threads/leader-exit-attach.exp
Pedro Alves ec48903170 New testcase gdb.threads/leader-exit-attach.exp (PR threads/8153)
Add a new testcase for exercising attaching to a process after its
main thread has exited.

This is not possible on Linux, the kernel does not allow attaching to
a zombie task, so the test is kfailed there.  It is possible however
on Windows at least, and was the scenario addressed by the Windows
backend fix in
https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html,
nowadays PR threads/8153, back in 2003.

Passes cleanly on Cygwin.
KFAILed on GNU/Linux native and gdbserver.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8153
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31555
Change-Id: Ib554f92f68c965bb4603cdf2aadb55ca45ded53b
2024-04-12 18:38:56 +01:00

88 lines
2.7 KiB
Plaintext

# Copyright (C) 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 attaching to a program after its main thread has exited.
require can_spawn_for_attach
standard_testfile leader-exit.c
if {[build_executable "failed to prepare" $testfile $srcfile {debug pthreads}] == -1} {
return
}
set escapedbinfile [string_to_regexp ${binfile}]
set test_spawn_id [spawn_wait_for_attach $binfile]
set testpid [spawn_id_get_pid $test_spawn_id]
# Wait a bit for the leader thread to exit, before attaching.
sleep 2
clean_restart ${binfile}
# Save this early as we may not be able to talk with GDBserver anymore
# when we need to check it.
set is_gdbserver [target_is_gdbserver]
# True if successfully attached.
set attached 0
gdb_test_multiple "attach $testpid" "attach" {
-re "Attaching to process $testpid failed.*" {
# GNU/Linux gdbserver. Linux ptrace does not let you attach
# to zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "warning: process $testpid is a zombie - the process has already terminated.*" {
# Native GNU/Linux. Linux ptrace does not let you attach to
# zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" {
pass $gdb_test_name
set attached 1
}
}
# With gdbserver, after we failed to attach, we hit PR server/31554:
# print $_inferior_thread_count
# Remote connection closed
# (gdb) KFAIL: gdb.threads/leader-exit-attach.exp: get valueof "$_inferior_thread_count"
if {!$attached && $is_gdbserver} {
setup_kfail "server/31554" "*-*-*"
}
set thread_count [get_valueof "" "\$_inferior_thread_count" -1]
if {$thread_count == -1} {
kill_wait_spawned_process $test_spawn_id
return
}
if {$attached} {
# Check that we have at least one thread. We can't assume there
# will only be exactly one thread, because on some systems, like
# Cygwin, the runtime spawns extra threads. Also, on Windows,
# attaching always injects one extra thread.
gdb_assert {$thread_count >= 1}
} else {
gdb_assert {$thread_count == 0}
}
kill_wait_spawned_process $test_spawn_id