gdb/testsuite: Fix race condition in gdb.base/skip.exp

gdb/testsuite: Fix race condition in gdb.base/skip.exp

In this commit:

  commit 5024637fac653914d471808288dc3221bc7ec089
  Date:   Sun Dec 15 11:05:47 2019 +0100

      Fix skip.exp test failure observed with gcc-9.2.0

A race condition was introduced into the gdb.base/skip.exp test when
this line:

    gdb_test "step" "foo \\(\\) at.*" "step 3"

Was changed to this:

    gdb_test "step" "foo \\(\\) at.*" "step 3" "main \\(\\) at .*" "step"

Before the above change we expected GDB to behave like this:

  (gdb) step
  foo () at /path/to/gdb/testsuite/gdb.base/skip.c:42
  42        return 0;
  (gdb)

However, when the test is compiled with GCC 9.2.0 we get a different
behaviour, and so we need a second 'step', like this:

  (gdb) step
  main () at /path/to/gdb.base/skip.c:32
  32        x = baz ((bar (), foo ()));
  (gdb) step
  foo () at /path/to/gdb/testsuite/gdb.base/skip.c:42
  42        return 0;
  (gdb)

Now the change to the test matches against 'main () at .*', however if
GDB or expect is being slow then we might only get to see output like
this:

  (gdb) step
  main () at /path/to/g

This will happily match the question pattern, so we send 'step' to GDB
again.  Now GDB continues to produce output which expect accepts, we
now see this:

  b.base/skip.c:32
  32        x = baz ((bar (), foo ()));
  (gdb)

This has carried on from where the previous block of output left off.
This doesn't match the final pattern 'foo \\(\\) at.*', but it does
match the prompt pattern that gdb_test_multiple adds, and so we report
the test as failing.

The solution is to simply ensure that the question consumes everything
up to, and including the prompt.  This ensures that the prompt can't
then match the failure case.  The new test line becomes:

    gdb_test "step" "foo \\(\\) at.*" "step 3" \
       "main \\(\\) at .*\r\n$gdb_prompt " "step"

gdb/testsuite/ChangeLog:

	* gdb.base/skip.exp: Fix race condition in test.

Change-Id: I9f0b0b52ef1b4f980bfaa8fe405ff06d520f3482