Why does remote_expect call the timeout/eof/default section if there is an error on the expect call?

[Pedro Alves]

A recent gdb patch caused a testsuite hang if the testsuite runs into
a tcl error.  The patch inadvertently ran into this feature in dejagnu:

      # remote_expect works basically the same as standard expect, but it
      # also takes care of getting the file descriptor from the specified
      # host and also calling the timeout/eof/default section if there is an
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      # error on the expect call.
        ^^^^^^^^^^^^^^^^^^^^^^^^
      #
      proc remote_expect { board timeout args } {

The hang happens because we have an eof section that calls wait on the
process, in order to get at its exit code.  When that eof section is called
by remote_expect in response to a tcl error, the wait hangs, because no
process actually exited.

Does anyone know/remember why that "feature" is there?  It doesn't make
much sense to me.  Seems very arbitrary to pick one of those sections
for this.  If an error section is needed at all, I'd think a separate section
named e.g., "error" as an extension over raw expect would be more appropriate.

The way remote_expect implements that, it gives preference to eof sections,
and, the last one wins.  So the workaround I'm using in GDB is to append
an eof section, but with an empty spawn id list, like

  -i "" eof {
     # Need comment here so this section isn't empty.
  }

so that it is never matched.

Lots more detail here:

 [PATCH] Fix testsuite hangs when gdb_test_multiple body errors out
 https://sourceware.org/ml/gdb-patches/2019-03/msg00484.html

Thanks,
Pedro Alves