[PATCH][gdb/testsuite] Detect gdb prompt after monitor exit

[Pedro Alves]

On 9/15/20 3:17 PM, Tom de Vries wrote:

> Anyway, this seems to work:
> ...
> index a2cc80f28d..24733275ae 100644
> --- a/gdb/testsuite/lib/gdbserver-support.exp
> +++ b/gdb/testsuite/lib/gdbserver-support.exp
> @@ -451,13 +451,20 @@ proc gdbserver_exit { is_mi } {
>             # We use expect rather than gdb_expect because
>             # we want to suppress printing exception messages, otherwise,
>             # remote_expect, invoked by gdb_expect, prints the exceptions.
> +           set have_prompt 0
>             expect {
>                 -i "$gdb_spawn_id" -re "$gdb_prompt $" {
> -                   exp_continue
> +                   if { [info exists server_spawn_id] } {
> +                       set have_prompt 1

I'd put this "set have_prompt 1" outside of the if, seems would read
clearer to me.

Otherwise LGTM.

> +                       exp_continue
> +                   }
>                 }
>                 -i "$server_spawn_id" eof {
>                     wait -i $expect_out(spawn_id)
>                     unset server_spawn_id
> +                   if { ! $have_prompt } {
> +                       exp_continue
> +                   }
>                 }
>                 timeout {
>                     warning "Timed out waiting for EOF in server after
> $monitor_exit"
> ...
> 
> I do wonder though about unsetting server_spawn_id and doing
> exp_continue while we still have the clause -i $server_spawn_id eof.  I
> wonder this is supported behaviour.

I'm not super sure, but I think it is, in that I don't think
the -i expression is reevaluated after exp_continue.

For example, this works:

$ cat exp.exp 
set fake_spawn_id foo

expect {
    -re "foo" {
        puts " got foo"
        if [info exists fake_spawn_id] {
            puts " unset"
            unset fake_spawn_id
        }
        exp_continue
    }
    -i "$fake_spawn_id" -re "bar" {
            puts " got bar?"
    }
}

$ expect exp.exp 
foo
 got foo
 unset
foo
 got foo
foo
 got foo
bar
foo
 got foo

If it turns out to be an issue, we can always use an indirect
spawn id instead:

  "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. "

Pedro Alves