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

[Pedro Alves <pedro@palves.net>]

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.