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

[Kevin Buettner <kevinb@redhat.com>]

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