gdb/testsuite: special case '^' in gdb_test pattern

In this commit I propose that we add special handling for the '^' when
used at the start of a gdb_test pattern.  Consider this usage:

  gdb_test "some_command" "^command output pattern"

I think the intention here is pretty clear - run 'some_command', and
the output from the command should be exactly 'command output
pattern'.

After the previous commit which tightened up how gdb_test matches the
final newline and prompt we know that the only thing after the output
pattern will be a single newline and prompt, and the leading '^'
ensures that there's no output before 'command output pattern', so
this will do what I want, right?

... except it doesn't.  The command itself will also needs to be
matched, so I should really write:

  gdb_test "some_command" "^some_command\r\ncommand output pattern"

which will do what I want, right?  Well, that's fine until I change
the command and include some regexp character, then I have to write:

  gdb_test "some_command" \
    "^[string_to_regexp some_command]\r\ncommand output pattern"

but this all gets a bit verbose, so in most cases I simply don't
bother anchoring the output with a '^', and a quick scan of the
testsuite would indicate that most other folk don't both either.

What I propose is this: the *only* thing that can appear immediately
after the '^' is the command converted into a regexp, so lets do that
automatically, moving the work into gdb_test.  Thus, when I write:

  gdb_test "some_command" "^command output pattern"

Inside gdb_test we will spot the leading '^' in the pattern, and
inject the regexp version of the command after the '^', followed by a
'\r\n'.

My hope is that given this new ability, folk will be more inclined to
anchor their output patterns when this makes sense to do so.  This
should increase our ability to catch any unexpected output from GDB
that appears as a result of running a particular command.

There is one problem case we need to consider, sometime people do
this:

  gdb_test "" "^expected output pattern"

In this case no command is sent to GDB, but we are still expecting
some output from GDB.  This might be a result of some asynchronous
event for example.  As there is no command sent to GDB (from the
gdb_test) there will be no command text to parse.

In this case my proposed new feature injects the command regexp, which
is the empty string (as the command itself is empty), but still
injects the '\r\n' after the command regexp, thus we end up with this
pattern:

  ^\r\nexpected output pattern

This extra '\r\n' is not what we should expected here, and so there is
a special case inside gdb_test -- if the command is empty then don't
add anything after the '^' character.

There are a bunch of tests that do already use '^' followed by the
command, and these can all be simplified in this commit.

I've tried to run all the tests that I can to check this commit, but I
am certain that there will be some tests that I manage to miss.
Apologies for any regressions this commit causes, hopefully fixing the
regressions will not be too hard.

Reviewed-By: Tom Tromey <tom@tromey.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/gdb/testsuite/gdb.mi/user-selected-context-sync.exp b/gdb/testsuite/gdb.mi/user-selected-context-sync.exp
index 9bcc90f..4889c31 100644
--- a/gdb/testsuite/gdb.mi/user-selected-context-sync.exp
+++ b/gdb/testsuite/gdb.mi/user-selected-context-sync.exp
@@ -500,7 +500,7 @@ proc ensure_no_output { test } {
     if { $gdb_spawn_id == $gdb_main_spawn_id } {
 	# CLI
 	gdb_test "print 666" \
-		 "^print 666\r\n\\\$$decimal = 666" \
+		 "^\\\$$decimal = 666" \
 		 "$test, ensure no output CLI"
     } elseif { $gdb_spawn_id == $mi_spawn_id } {
 	# MI