Re: [PATCH 1/2] gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver

[Pedro Alves <pedro@palves.net>]

On 2022-04-27 19:17, Andrew Burgess via Gdb-patches wrote:
> When running the gdb.mi/mi-exec-run.exp test using the
> native-extended-gdbserver I see failures like this:
> 
>   FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected
>   FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected
>   FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected
> 
> There's a race condition here, so you might see a slightly different
> set of failures, but I always see some from the 'run failure detected'
> test.
> 
> NOTE: I also see an additional test failure:
> 
>  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
> 
> but that is a completely different issue, and is not being addressed
> in this commit.
> 
> The problem for the 'run failure detected' test is that we end up
> in gdb_expect looking for output from two spawn-ids, one from
> gdbserver, and one from gdb.  We're looking for one output pattern
> from each spawn-id, and for the test to pass we need to see both
> patterns.
> 
> Now, if gdb exits then this is a test failure (this would indicate gdb
> crashing, which is bad), so we have the eof pattern associated with
> the gdb spawn-id.
> 
> However, in this particular test we expect gdbserver to fail to
> execute the binary (the test binary is set non-executable), and so we
> get an error message from gdbserver (which matches the pattern), and
> then gdbserver exits, this is expected.
> 
> In our gdb_expect call we don't have an eof pattern for gdbserver, and
> so, when gdbserver exits, expect sees eof and drops out of the
> gdb_expect call.
> 
> If both the gdbserver AND gdb patterns are seen before the gdbserver
> eof triggers then everything is fine.
> 
> But, if expect sees gdbserver's eof before seeing the output from gdb
> then we will exit the gdb_expect call, and (as we have not seen both
> patterns) we will call 'fail'.
> 
> I initially tried to fix this by adding a new eof pattern for the
> gdbserver spawn-id that called exp_continue, however, this causes
> expect to throw an error, it is not happy to have '-i' options that
> make use of a closed spawn-id.
> 

I suspect this will look simpler if you use an indirect spawd id.  Did you try that?

From the expect man page:

  "The -i flag may also name a global variable in which case the variable is read for a
   list of spawn ids. The variable is reread whenever it changes. This provides a way of
   changing the I/O source while the command is in execution. Spawn ids provided this way
   are called "indirect" spawn ids."

Some other testcases use this technique to handle scenarios similar to what you
describe, of not wanting to expect output out of a spawn_id anymore.
E.g., gdb.base/interrupt.exp has:

        set spawn_list "$inferior_spawn_id"

        gdb_test_multiple "" $msg {
            -i spawn_list -re "end of file" {
                set saw_end_of_file 1
                verbose -log "saw \"end of file\""
                if {!$saw_inferior_exit} {
                    # When $inferior_spawn_id != $gdb_spawn_id, such
                    # as when testing with gdbserver, we may see the
                    # eof (the process exit, not the string just
                    # matched) for $inferior_spawn_id before the
                    # expected gdb output.  Clear this so we no longer
                    # expect anything out of $inferior_spawn_id.
                    set spawn_list ""
                    exp_continue
                }
            }
       [...]