Re: [PATCH v5 2/2] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp

Kevin Buettner via Gdb-patches
2022-03-18T20:44:17Z

I've spent a few more minutes looking at the current version
of can_spawn_for_attach. The latter part of it currently looks
like this:

...
gdb_test_multiple "attach $test_pid" "can spawn for attach" {
-re -wrap "Attaching to process $test_pid\r\n.*No executable file now.*" {
pass $gdb_test_name
kill_wait_spawned_process $test_spawn_id
return 1
}
-re -wrap "Attaching to process $test_pid\r\n.*ptrace: Operation not permitted\\." {
unsupported "$gdb_test_name (Operation not permitted)"
kill_wait_spawned_process $test_spawn_id
return 0
}
-re -wrap "Attaching to process $test_pid\r\n.*Attaching to process $test_pid failed" {
unsupported "$gdb_test_name (Attaching to process failed)"
kill_wait_spawned_process $test_spawn_id
return 0
}
-re -wrap "Attaching to process $test_pid\r\n.*XML support was disabled at compile time.*" {
pass $gdb_test_name
kill_wait_spawned_process $test_spawn_id
return 1
}
-re "A program is being debugged already. Kill it. .y or n. " {
send_gdb "y\n"
exp_continue
}
}

kill_wait_spawned_process $test_spawn_id

# Assume yes.
return 1
}

Note that there are return statements for all but one of the
gdb_test_multiple cases with a final return (assuming yes) at the end
of the proc. Assuming "yes" seems wrong to me; when
gdb_test_multiple fails (due to not matching any of the explicit REs),
it'll FAIL. I think we should be returning 0 when that happens.
However, this means that you'll need to match all cases which
should pass and return 1 for those cases.

I also think you revisit Pedro's remarks regarding caching procs
passing or failing here:

https://sourceware.org/pipermail/gdb-patches/2022-March/186311.html

Kevin