[2/7,gdb/testsuite] Fix gdb.server/server-kill.exp for remote target
Commit Message
In commit 80dc83fd0e7 ("gdb/remote: handle target dying just before a stepi")
an observation is made that test-case gdb.server/server-kill.exp claims to
kill gdbserver, but actually kills the inferior. Consequently, the commit
adds testing of killing gdbserver alongside.
The problem is that:
- the original observation is incorrect (possibly caused by misreading getppid
as getpid)
- consequently, the test-case doesn't test killing the inferior, instead it
tests killing gdbserver twice
- the method to get the gdbserver PID added in the commit doesn't work
for target board remote-gdbserver-on-localhost, it returns the
PID of the ssh client session instead.
Fixing the method for getting the inferior PID gives us fails, and there's no
evidence that killing the inferior ever worked.
So, fix this by reverting the commit and just killing gdbserver, using the
original method of getting the gdbserver PID which does work for target board
remote-gdbserver-on-localhost.
Tested on x86_64-linux.
---
gdb/testsuite/gdb.server/server-kill.exp | 47 +++++-------------------
1 file changed, 10 insertions(+), 37 deletions(-)
@@ -28,21 +28,6 @@ if { [build_executable "failed to prepare" ${testfile}] } {
return -1
}
-# Global control variable used by the proc prepare. Should be set to
-# either 'inferior' or 'server'.
-#
-# In the proc prepare we start gdbserver and extract a pid, which will
-# later be killed by calling the proc kill_server.
-#
-# When KILL_PID_OF is set to 'inferior' then the pid we kill is that
-# of the inferior running under gdbserver, when this process dies
-# gdbserver itself will exit.
-#
-# When KILL_PID_OF is set to 'server' then the pid we kill is that of
-# the gdbserver itself, this is a much more aggressive strategy and
-# exposes different bugs within GDB.
-set kill_pid_of "inferior"
-
# Spawn GDBserver, run to main, extract GDBserver's PID and save it in
# the SERVER_PID global.
@@ -67,24 +52,16 @@ proc prepare {} {
gdbserver_run ""
- # Continue past server_pid assignment. We do this for both scenarios,
- # to avoid doing a backtrace from _start, which may not trigger remote
- # communication.
gdb_breakpoint ${srcfile}:[gdb_get_line_number "i = 0;"]
gdb_continue_to_breakpoint "after server_pid assignment"
- if { $::kill_pid_of == "inferior" } {
- # Get the pid of GDBServer.
- set test "p server_pid"
- set server_pid 0
- gdb_test_multiple $test $test {
- -re " = ($decimal)\r\n$gdb_prompt $" {
- set server_pid $expect_out(1,string)
- pass $test
- }
+ # Get the pid of GDBServer.
+ set server_pid 0
+ gdb_test_multiple "p server_pid" "" {
+ -re -wrap " = ($decimal)" {
+ set server_pid $expect_out(1,string)
+ pass $gdb_test_name
}
- } else {
- set server_pid [exp_pid -i $::server_spawn_id]
}
if {$server_pid == 0} {
@@ -165,12 +142,8 @@ proc_with_prefix test_stepi {} {
gdb_test "stepi" "(Target disconnected|Remote connection closed|Remote communication error).*"
}
-# Run each test twice, see the description of KILL_PID_OF earlier in
-# this file for more details.
+test_tstatus
+test_unwind_nosyms
+test_unwind_syms
+test_stepi
-foreach_with_prefix kill_pid_of { "inferior" "server" } {
- test_tstatus
- test_unwind_nosyms
- test_unwind_syms
- test_stepi
-}