[PATCH v5 2/2] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
Pedro Alves
pedro@palves.net
Thu Mar 3 18:45:13 GMT 2022
On 2022-02-23 02:45, Tiezhu Yang wrote:
> -proc can_spawn_for_attach { } {
> +gdb_caching_proc can_spawn_for_attach {
> # We use exp_pid to get the inferior's pid, assuming that gives
> # back the pid of the program. On remote boards, that would give
> # us instead the PID of e.g., the ssh client, etc.
> @@ -5079,6 +5079,42 @@ proc can_spawn_for_attach { } {
> return 0
> }
>
> + set me "can_spawn_for_attach"
> + set src { int main (void) { sleep (600); return 0; } }
> + if {![gdb_simple_compile $me $src executable]} {
> + return 0
> + }
> +
> + set test_spawn_id [spawn_wait_for_attach $obj]
> + set test_pid [spawn_id_get_pid $test_spawn_id]
> +
> + gdb_start
> + file delete $obj
> + 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
I don't think caching procs should issue pass/fail, as whether the proc does anything
depends on whether the result was cached before. It seems weird to get a PASS/FAIL
depending on whether the result was cached or not earlier.
> + kill_wait_spawned_process $test_spawn_id
> + return 1
I have to say this whole thing seems completely backwards to me. We are checking
whether we can spawn a program for attaching, by spawning a program for attaching,
and then attaching... If the "attach" command has some kind of bug, then we will
fail can_spawn_for_attach instead of having that proc return true, and then letting
the proper "attach" tests fail.
Why isn't this all solved by leaving can_spawn_for_attach alone, and then making
the "attach" tests bail out on failure to attach. We could add some new
gdb_attach proc to centralize the failure checking.
More information about the Gdb-patches
mailing list