gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test

I saw some failures in the test gdb.mi/mi-multi-commands.exp that I
added recently.  This test was added in commit:

  commit d08cbc5d3203118da5583296e49273cf82378042
  Date:   Wed Dec 22 12:57:44 2021 +0000

      gdb: unbuffer all input streams when not using readline

The failures I see only occurred when my machine was very heavily
loaded.

In this test I send multiple commands from dejagnu to gdb with a
single send_gdb call.  In a well behaving world what I want to happen
is that the gdb console sees both commands arrive and echos the text
of those commands.  Then gdb starts processing the first command,
prints the result, and then processes the second command, and prints
the result.

However, what I saw in my loaded environment was that only after
sending the two commands, only the first command was echoed to gdb's
terminal.  Then gdb started processing the first command, and started
to write the output.  Now, mixed in with the first command output, the
second command was echoed to gdb's terminal.  Finally, gdb would
finish printing the first command output, and would read and handle
the second command.

This mixing of command echoing with the first command output was
causing the test matching patterns to fail.

In this commit I change the command I use in the test from a CLI
command to an MI command, this reduces the number of lines of output
that come from the test, CLI commands sent through the MI interpreter
are echoed back like this:

  (gdb)
  set $a = "FIRST COMMAND"
  &"set $a = \"FIRST COMMAND\"\n"
  ^done
  (gdb)

While this is not the case for true MI command:

  (gdb)
  -data-evaluate-expression $a
  ^done,value="\"FIRST COMMAND\""
  (gdb)

Less output makes for simpler patterns to match against.

Next, when sending two command to gdb I was previously trying to spot
the output of the first command followed by the prompt with nothing
between.  This is not really needed, for the first command I can look
for just the ^done,value="\"FIRST COMMAND\"" string, then I can start
looking for the output of the second command.

So long as the second pattern matches up to the gdb prompt, then I can
be sure than nothing is left over in the expect buffer to muck up
later matches.

As to see the second command output gdb must have read in the second
command, the second command output never suffers from the corruption
that the first command output does.

Since making this change, I've not seen a failure in this test.

0 files changed, 0 insertions, 0 deletions