Fix testsuite race with multi-line commands

["Joseph S. Myers" <joseph at codesourcery dot com>]

I have observed failures in remote-host GDB testing of the form:

(gdb) PASS: gdb.arch/i386-prologue.exp: continue to standard
if (*(unsigned char *)$pc == 0xcc)
 >set $pc = $pc + 1
end
 >(gdb) FAIL: gdb.arch/i386-prologue.exp: skip breakpoint in standard (timeout)

where for local-host things look like:

(gdb) PASS: gdb.arch/i386-prologue.exp: continue to standard
if (*(unsigned char *)$pc == 0xcc)
 >set $pc = $pc + 1
 >end
(gdb) PASS: gdb.arch/i386-prologue.exp: skip breakpoint in standard

That is, the difference is where the secondary " >" prompt comes:
before or after the "end" command is sent.  If before, the (gdb)
prompt is properly detected at the start of a line and the test
passes; if after, (gdb) is not detected because it's not at the start
of a line and the test times out.

There is code in gdb_test_multiple that tries to handle multi-line
commands and ensure that each line is accepted by GDB before sending
the next one:

                # since we're checking if each line of the multi-line
                # command are 'accepted' by GDB here,
                # we need to set -notransfer expect option so that
                # command output is not lost for pattern matching
                # - guo
                gdb_expect 2 {
                    -notransfer -re "\[\r\n\]" { verbose "partial: match" 3 }
                    timeout { verbose "partial: timeout" 3 }
                }
                set string [string range "$string" [expr $foo + 1] end];

There are two reasons this cannot work reliably (and so there could be
intermittent failures from this cause on any host, although they may
be more likely for remote hosts because of the greater transmission
delays in commands getting to GDB):

* The -notransfer means that the first newline - from the first line
of the command - will be considered again each time through this
gdb_expect, so that for commands of three or more lines the testsuite
will not wait at all to send third and subsequent commands.

* In any case, it's not enough for the newline to have appeared before
the last command - the prompt must have appeared as well.

This patch fixes this problem by expecting prompts explicitly, and
adding an extra newline-and-prompt to the expected regular expression
for every line in the command (I have looked for cases in the
testsuite passing multi-line commands here, and they all do appear to
be cases where the ">" prompt should be expected).  Tested with no
regressions on i686-pc-linux-gnu, and it also appears to fix the
observed problem with remote-host testing.  OK to commit?

2011-10-13  Joseph Myers  <joseph@codesourcery.com>

	* lib/gdb.exp (gdb_test_multiple): Expect newline and secondary
	prompt for each extra line in command.

Index: lib/gdb.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.189
diff -u -p -r1.189 gdb.exp
--- lib/gdb.exp	29 Sep 2011 15:17:50 -0000	1.189
+++ lib/gdb.exp	13 Oct 2011 12:56:03 -0000
@@ -677,6 +677,7 @@ proc gdb_test_multiple { command message
     set result -1
     set string "${command}\n";
     if { $command != "" } {
+	set multi_line_re "\[\r\n\] *>"
 	while { "$string" != "" } {
 	    set foo [string first "\n" "$string"];
 	    set len [string length "$string"];
@@ -697,10 +698,11 @@ proc gdb_test_multiple { command message
 		# command output is not lost for pattern matching
 		# - guo
 		gdb_expect 2 {
-		    -notransfer -re "\[\r\n\]" { verbose "partial: match" 3 }
+		    -notransfer -re "$multi_line_re" { verbose "partial: match" 3 }
 		    timeout { verbose "partial: timeout" 3 }
 		}
 		set string [string range "$string" [expr $foo + 1] end];
+		set multi_line_re "$multi_line_re.*\[\r\n\] *>"
 	    } else {
 		break;
 	    }

-- 
Joseph S. Myers
joseph@codesourcery.com