Use gdb_test_sequence in gdb.base/save-bp.exp.

But IMO it is a functionality regression as:

 * gdb_test_sequence permits arbitary number of lines of text between those
   lines being matched.  Former regex string did not allow it.
   This may make a difference if GDB regresses by printing some unexpected
   line after the breakpoint info line (like a "silent" line).

>  * \[\r\n\]+ can be used to anchor the beginning of the pattern, in the sense
>    of Perl regex ^ /m match.  At least I have found such cases in existing
>    *.exp files so I used that.  Using ^ really does not work.
>
>    But I am not aware how to do Perl regex $ /m match.  Using $ really does
>    not work.  But this means that for example the trailing
>      ( \\((host|target) evals\\))?
>    on the line
>      "\[\r\n\]+\[ \t\]+stop only if i == 1( \\((host|target) evals\\))?"
>    originally made sense there but now it can be removed as it has no longer
>    any functionality there - it will match now any trailing line garbage.

by Yao Qi:

In this test case, ( \\((host|target) evals\\))? isn't needed in the
pattern.  What we test here is to save breakpoints into file and restore
them from file.  The contents saved in file are:

break save-bp.c:31
  condition $bpnum i == 1

the information about the place where the condition is evaluated isn't
saved, so we don't need to check.  Breakpoint save and restore has
nothing to do with where the condition is evaluated (host or target).  I
am fine to leave it here now.

gdb/testsuite/ChangeLog
2014-10-09  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.base/save-bp.exp (info break): Use gdb_test_sequence.

0 files changed, 0 insertions, 0 deletions