[commit/obvious/testsuite] structs.exp: start a fresh gdb for each executable

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

Here's another anti-timeout patch.

structs.exp runs 24 different executables.  The current script calls
gdb_start, which tells dejagnu to re-use the same gdb for each new
executable.  That's no good.

On native hppa2.0w-hp-hpux11.11, gdb loses its marbles on executable #6,
structs-tf.  Hundreds of timeouts follow as the test script keeps
talking to the dead gdb.  I let 'make check' run for three hours and it
got from executable #6 to executable #11.  The whole script would
probably take about nine hours at this rate.

Also, every result after executable #6 is worthless.

This patch calls gdb_exit before gdb_start, which tells dejagnu to start
a fresh gdb.  This is the usual idiom for starting gdb.

I tested this with:

  native i686-pc-linux-gnu, gcc 2.95.3 and gcc 3.3.2, dwarf-2 and stabs+
  native hppa2.0w-hp-hpux11.11, gcc 3.3.2, default -g format

The average run time on native i686-pc-linux-gnu increased from 24
seconds to 27 seconds.  The run time on native hppa2.0w-hp-hpux11.11
dropped to 1896 seconds (there are still plenty of timeouts).

I am committing this as an obvious fix.

Michael C

2003-12-16  Michael Chastain  <mec.gnu@mindspring.com>

	* gdb.base/structs.exp: Call gdb_exit as well as gdb_start.

Index: structs.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/structs.exp,v
retrieving revision 1.13
diff -c -3 -p -r1.13 structs.exp
*** structs.exp	6 Dec 2003 22:49:02 -0000	1.13
--- structs.exp	17 Dec 2003 05:04:40 -0000
*************** proc start_structs_test { types } {
*** 81,86 ****
--- 81,87 ----
      }
  
      # Start with a fresh gdb.
+     gdb_exit
      gdb_start
      gdb_reinitialize_dir $srcdir/$subdir
      gdb_load ${binfile}