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>

3 files changed, 49 insertions, 18 deletions

diff --git a/gdb/testsuite/gdb.arch/amd64-entry-value.exp b/gdb/testsuite/gdb.arch/amd64-entry-value.exp
index a700e9a..3c666ac 100644
--- a/gdb/testsuite/gdb.arch/amd64-entry-value.exp
+++ b/gdb/testsuite/gdb.arch/amd64-entry-value.exp
@@ -48,8 +48,11 @@ gdb_breakpoint "breakhere_reference"
 
 gdb_continue_to_breakpoint "entry: breakhere"
 
-gdb_test "bt" "^bt\r\n#0 +d *\\(i=31, i@entry=30, j=31\\.5, j@entry=30\\.5\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in main .*" \
-	 "entry: bt"
+gdb_test "bt" \
+    [multi_line \
+	 "^#0 +d *\\(i=31, i@entry=30, j=31\\.5, j@entry=30\\.5\\) \[^\r\n\]*" \
+	 "#1 +0x\[0-9a-f\]+ in main .*"] \
+    "entry: bt"
 gdb_test "p i" " = 31" "entry: p i"
 gdb_test "p i@entry" " = 30" "entry: p i@entry"
 gdb_test "p j" { = 31\.5} "entry: p j"
@@ -61,21 +64,30 @@ gdb_test "p j@entry" { = 30\.5} "entry: p j@entry"
 gdb_continue_to_breakpoint "entry_locexpr: breakhere_locexpr"
 gdb_test "p i" " = 30" "entry_locexpr: p i"
 gdb_test_no_output "set variable i = 0" "entry_locexpr: set variable i = 0"
-gdb_test "bt" "^bt\r\n#0 +locexpr *\\(i=0, i@entry=30\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in main .*" \
-	 "entry_locexpr: bt"
+gdb_test "bt" \
+    [multi_line \
+	 "^#0 +locexpr *\\(i=0, i@entry=30\\) \[^\r\n\]*" \
+	 "#1 +0x\[0-9a-f\]+ in main .*"] \
+    "entry_locexpr: bt"
 
 
 # Test @entry values for stack passed parameters.
 
 gdb_continue_to_breakpoint "entry_stack: stacktest"
 
-gdb_test "bt" "^bt\r\n#0 +stacktest *\\(r1=r1@entry=1, r2=r2@entry=2, \[^\r\n\]+, s1=s1@entry=11, s2=s2@entry=12, \[^\r\n\]+, d9=d9@entry=11\\.5, da=da@entry=12\\.5\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in main .*" \
-	 "entry_stack: bt at entry"
+gdb_test "bt" \
+    [multi_line \
+	 "^#0 +stacktest *\\(r1=r1@entry=1, r2=r2@entry=2, \[^\r\n\]+, s1=s1@entry=11, s2=s2@entry=12, \[^\r\n\]+, d9=d9@entry=11\\.5, da=da@entry=12\\.5\\) \[^\r\n\]*" \
+	 "#1 +0x\[0-9a-f\]+ in main .*"] \
+    "entry_stack: bt at entry"
 
 gdb_continue_to_breakpoint "entry_stack: breakhere_stacktest"
 
-gdb_test "bt" "^bt\r\n#0 +stacktest *\\(r1=r1@entry=1, r2=r2@entry=2, \[^\r\n\]+, s1=3, s1@entry=11, s2=4, s2@entry=12, \[^\r\n\]+, d9=3\\.5, d9@entry=11\\.5, da=4\\.5, da@entry=12\\.5\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in main .*" \
-	 "entry_stack: bt"
+gdb_test "bt" \
+    [multi_line \
+	 "^#0 +stacktest *\\(r1=r1@entry=1, r2=r2@entry=2, \[^\r\n\]+, s1=3, s1@entry=11, s2=4, s2@entry=12, \[^\r\n\]+, d9=3\\.5, d9@entry=11\\.5, da=4\\.5, da@entry=12\\.5\\) \[^\r\n\]*" \
+	 "#1 +0x\[0-9a-f\]+ in main .*"] \
+    "entry_stack: bt"
 
 gdb_test "p s1" " = 3" "entry_stack: p s1"
 gdb_test "p s1@entry" " = 11" "entry_stack: p s1@entry"
@@ -202,8 +214,13 @@ gdb_test "p nodataparam@entry" "Cannot resolve DW_AT_call_data_value" "entry_ref
 
 gdb_continue_to_breakpoint "tailcall: breakhere"
 
-gdb_test "bt" "^bt\r\n#0 +d *\\(i=71, i@entry=70, j=73\\.5, j@entry=72\\.5\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in c \\(i=i@entry=7, j=j@entry=7\\.25\\) \[^\r\n\]*\r\n#2 +0x\[0-9a-f\]+ in b \\(i=i@entry=5, j=j@entry=5\\.25\\) \[^\r\n\]*\r\n#3 +0x\[0-9a-f\]+ in main \[^\r\n\]*" \
-	 "tailcall: bt"
+gdb_test "bt" \
+    [multi_line \
+	 "^#0 +d *\\(i=71, i@entry=70, j=73\\.5, j@entry=72\\.5\\) \[^\r\n\]*" \
+	 "#1 +0x\[0-9a-f\]+ in c \\(i=i@entry=7, j=j@entry=7\\.25\\) \[^\r\n\]*" \
+	 "#2 +0x\[0-9a-f\]+ in b \\(i=i@entry=5, j=j@entry=5\\.25\\) \[^\r\n\]*" \
+	 "#3 +0x\[0-9a-f\]+ in main \[^\r\n\]*"] \
+    "tailcall: bt"
 gdb_test "p i" " = 71" "tailcall: p i"
 gdb_test "p i@entry" " = 70" "tailcall: p i@entry"
 gdb_test "p j" " = 73\\.5" "tailcall: p j"
@@ -243,8 +260,16 @@ gdb_test_multiple $test $test {
 
 gdb_continue_to_breakpoint "ambiguous: breakhere"
 
-gdb_test "bt" "^bt\r\n#0 +d \\(i=<optimized out>, j=<optimized out>\\)\[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in amb_z \\(i=<optimized out>\\)\[^\r\n\]*\r\n#2 +0x\[0-9a-f\]+ in amb_y \\(i=<optimized out>\\)\[^\r\n\]*\r\n#3 +0x\[0-9a-f\]+ in amb_x \\(i=<optimized out>\\)\[^\r\n\]*\r\n#4 +0x\[0-9a-f\]+ in amb_b \\(i=i@entry=101\\)\[^\r\n\]*\r\n#5 +0x\[0-9a-f\]+ in amb_a \\(i=i@entry=100\\)\[^\r\n\]*\r\n#6 +0x\[0-9a-f\]+ in main \\(\\)\[^\r\n\]*" \
-	 "ambiguous: bt"
+gdb_test "bt" \
+    [multi_line \
+	 "^#0 +d \\(i=<optimized out>, j=<optimized out>\\)\[^\r\n\]*" \
+	 "#1 +0x\[0-9a-f\]+ in amb_z \\(i=<optimized out>\\)\[^\r\n\]*" \
+	 "#2 +0x\[0-9a-f\]+ in amb_y \\(i=<optimized out>\\)\[^\r\n\]*" \
+	 "#3 +0x\[0-9a-f\]+ in amb_x \\(i=<optimized out>\\)\[^\r\n\]*" \
+	 "#4 +0x\[0-9a-f\]+ in amb_b \\(i=i@entry=101\\)\[^\r\n\]*" \
+	 "#5 +0x\[0-9a-f\]+ in amb_a \\(i=i@entry=100\\)\[^\r\n\]*" \
+	 "#6 +0x\[0-9a-f\]+ in main \\(\\)\[^\r\n\]*"] \
+    "ambiguous: bt"
 
 
 # Test self tail calls verification.
@@ -252,8 +277,14 @@ gdb_test "bt" "^bt\r\n#0 +d \\(i=<optimized out>, j=<optimized out>\\)\[^\r\n\]*
 
 gdb_continue_to_breakpoint "self: breakhere"
 
-gdb_test "bt" "^bt\r\n#0 +d \\(i=<optimized out>, j=<optimized out>\\)\[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in self \\(i=<optimized out>\\)\[^\r\n\]*\r\n#2 +0x\[0-9a-f\]+ in self2 \\(i=<optimized out>\\)\[^\r\n\]*\r\n#3 +0x\[0-9a-f\]+ in self \\(i=<optimized out>\\)\[^\r\n\]*\r\n#4 +0x\[0-9a-f\]+ in main \\(\\)\[^\r\n\]*" \
-	 "self: bt"
+gdb_test "bt" \
+    [multi_line \
+	 "^#0 +d \\(i=<optimized out>, j=<optimized out>\\)\[^\r\n\]*" \
+	 "#1 +0x\[0-9a-f\]+ in self \\(i=<optimized out>\\)\[^\r\n\]*" \
+	 "#2 +0x\[0-9a-f\]+ in self2 \\(i=<optimized out>\\)\[^\r\n\]*" \
+	 "#3 +0x\[0-9a-f\]+ in self \\(i=<optimized out>\\)\[^\r\n\]*" \
+	 "#4 +0x\[0-9a-f\]+ in main \\(\\)\[^\r\n\]*"] \
+    "self: bt"
 
 gdb_test_no_output "set debug entry-values 1"
 gdb_test "bt" "DW_OP_entry_value resolving has found function \"self\\(int\\)\" at 0x\[0-9a-f\]+ can call itself via tail calls\r\n.*" \
diff --git a/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.exp b/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.exp
index 156300b..c90b92c 100644
--- a/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.exp
+++ b/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.exp
@@ -39,10 +39,10 @@ if ![runto breakpt] {
     return -1
 }
 
-gdb_test "bt" "^bt\r\n#0 +breakpt *\\(\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in func5\[^\r\n\]*\r\n#2 +0x\[0-9a-f\]+ in func4\[^\r\n\]*\r\n#3 +0x\[0-9a-f\]+ in func3\[^\r\n\]*\r\nBacktrace stopped: Cannot access memory at address 0x\[0-9a-f\]+" \
+gdb_test "bt" "^#0 +breakpt *\\(\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in func5\[^\r\n\]*\r\n#2 +0x\[0-9a-f\]+ in func4\[^\r\n\]*\r\n#3 +0x\[0-9a-f\]+ in func3\[^\r\n\]*\r\nBacktrace stopped: Cannot access memory at address 0x\[0-9a-f\]+" \
 	 "first backtrace, with error message"
 
-gdb_test "bt" "^bt\r\n#0 +breakpt *\\(\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in func5\[^\r\n\]*\r\n#2 +0x\[0-9a-f\]+ in func4\[^\r\n\]*\r\n#3 +0x\[0-9a-f\]+ in func3\[^\r\n\]*\r\nBacktrace stopped: Cannot access memory at address 0x\[0-9a-f\]+" \
+gdb_test "bt" "^#0 +breakpt *\\(\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in func5\[^\r\n\]*\r\n#2 +0x\[0-9a-f\]+ in func4\[^\r\n\]*\r\n#3 +0x\[0-9a-f\]+ in func3\[^\r\n\]*\r\nBacktrace stopped: Cannot access memory at address 0x\[0-9a-f\]+" \
 	 "second backtrace, with error message"
 
 clean_restart ${binfile}
diff --git a/gdb/testsuite/gdb.arch/amd64-invalid-stack-top.exp b/gdb/testsuite/gdb.arch/amd64-invalid-stack-top.exp
index b6a25f8..03edcef 100644
--- a/gdb/testsuite/gdb.arch/amd64-invalid-stack-top.exp
+++ b/gdb/testsuite/gdb.arch/amd64-invalid-stack-top.exp
@@ -43,10 +43,10 @@ if ![runto breakpt] {
 # Use 'bt no-filters' here as the python filters will raise their own
 # error during initialisation, the no-filters case is simpler.
 
-gdb_test "bt no-filters" "^bt no-filters\r\n#0 +$hex in func2 \\(\\)\r\nBacktrace stopped: Cannot access memory at address 0x\[0-9a-f\]+" \
+gdb_test "bt no-filters" "^#0 +$hex in func2 \\(\\)\r\nBacktrace stopped: Cannot access memory at address 0x\[0-9a-f\]+" \
 	 "first backtrace, with error message"
 
-gdb_test "bt no-filters" "^bt no-filters\r\n#0 +$hex in func2 \\(\\)\r\nBacktrace stopped: Cannot access memory at address 0x\[0-9a-f\]+" \
+gdb_test "bt no-filters" "^#0 +$hex in func2 \\(\\)\r\nBacktrace stopped: Cannot access memory at address 0x\[0-9a-f\]+" \
 	 "second backtrace, with error message"
 
 clean_restart ${binfile}