gdb/testsuite: gdb.base/attach.exp: expose bug when testing with native-extended-gdbserver

In gdb.base/attach.exp, proc do_attach_failure_tests, we attach to a
process.  When then try to attach to the same process in another
inferior, expecting it to fail.  We then come back to the first inferior
and try to kill it, to clean up the test.  When using the
native-extended-gdbserver board, this "kill" test passes, even though it
didn't actually work:

    add-inferior
    [New inferior 2]
    Added inferior 2 on connection 1 (extended-remote localhost:2347)
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: add empty inferior 2
    inferior 2
    [Switching to inferior 2 [<null>] (<noexec>)]
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 2
    attach 817032
    Attaching to process 817032
    Attaching to process 817032 failed
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again
    inferior 1
    [Switching to inferior 1 [process 817032] (/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/attach/attach)]
    [Switching to thread 1.1 (Thread 817032.817032)]
    #0  main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19
    19	  while (! should_exit)
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 1
    kill
    Kill the program being debugged? (y or n) y
    Remote connection closed  <==== That's unexpected
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: exit after attach failures

When the second attach fails, gdbserver seems to break the connection
(it hangs up on the existing remote target) and start listening again
for incoming connections.  This is documented in PR 19558 [1].

Make the expected output regexp for the kill command tighter (it
currently accepts anything).  Use "set confirm off" so we don't have to
deal with the confirmation.  And to be really sure the extended-remote
target still works, try to run the inferior again after killing.  The
now tests are kfail'ed when the target is gdbserver.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=19558

gdb/testsuite/ChangeLog:

	* gdb.base/attach.exp (do_attach_failure_tests): Make kill
	regexp tighter, run inferior after killing it.  Kfail when
	target is gdbserver.

Change-Id: I99c5cd3968ce2ec962ace35b016f842a243b7a0d
This commit is contained in:
Simon Marchi
2021-06-10 10:47:40 -04:00
parent 52e0e32b34
commit 4b0cf3d6d0

View File

@ -179,6 +179,10 @@ proc_with_prefix do_attach_failure_tests {} {
gdb_test "add-inferior" "Added inferior 2.*" "add empty inferior 2"
gdb_test "inferior 2" "Switching to inferior 2.*" "switch to inferior 2"
# Probe this before the failing attach: the failed attach against GDBserver
# currently leaves the extended-remote target in a bad state.
set do_kfail [target_is_gdbserver]
set test "fail to attach again"
gdb_test_multiple "attach $testpid" "$test" {
-re "Attaching to process $testpid.*warning: process .* is already traced by process .*$gdb_prompt $" {
@ -190,13 +194,24 @@ proc_with_prefix do_attach_failure_tests {} {
}
}
# To ensure the target is still alive and working after this, try to run
# inferior 1.
gdb_test_no_output "set confirm off"
gdb_test "inferior 1" "Switching to inferior 1.*" "switch to inferior 1"
set test "exit after attach failures"
gdb_test "kill" \
"" \
"$test" \
"Kill the program being debugged.*y or n. $" \
"y"
if { $do_kfail } { setup_kfail "gdb/19558" "*-*-*" }
gdb_test "kill" "killed.*" "exit after attach failures"
# This can probably be replaced with a call to runto or runto_main once
# the kfail is removed.
gdb_breakpoint "main"
gdb_run_cmd
if { $do_kfail } { setup_kfail "gdb/19558" "*-*-*" }
gdb_test_multiple "" "stop at main" {
-wrap -re "Breakpoint $::decimal, main .*" {
pass $gdb_test_name
}
}
# Another "don't leave a process around"
kill_wait_spawned_process $test_spawn_id