Re: testcase for "absolute source" patch

[Michael Chastain <mec dot gnu at mindspring dot com>]

Good morning Barjaun,

More feedback.  This is all still shallow stuff.  In another 1-2 rounds,
all the shallow stuff will be fixed, and also enough of the code will
have permeated my brain that I can actually talk about the real
contents.

. The script works for me now when I run it several times in a row
  with different gdb's, gcc's, and debug formats.

. Include openp.c as a second attachment to your mail.

. ChangeLog entry

. if [is_remote host] {
    unresolved "This test script does not work on a remote host."
    return -1
  }

. error checking on calls to remote_exec

. gdb_suppress_entire_file is rotten and obsolete.
  if gdb_compile fails, just do:

    if {[gdb_compile ...] != ""} {
      perror "Testcase compile failed" 0
      return -1
    }

  and then check the return value from cdir_compile

. the convention for gdb_start and gdb_exit is to assume that the
  previous test script left a gdb running and to call gdb_exit
  first, followed by gdb_start.

. in test_bin, don't move the file back and forth -- just copy
  the file and then leave the copy in place.  disk space is cheap,
  and "mv $binfile $bin_dir ... $mv $bin_dir/$binname $binfile"
  is vulnerable to cascade failures when you call test_bin 13
  times in a row and one of them might de-synchronize.
  same with test_src.

  Or am i missing something and it will screw up some tests if
  you let the prime copies of $srcfile and $binfile exist
  all the time?

. in test_src, drop the semicolons here:

    global srcname;
    global srcfile;

. don't bother to do "remote_exec host rm $srcfile"

In general, for file handling, just create and copy things and don't
delete or move them.  That makes it easier to debug your script or debug
gdb when something doesn't work.  Just be prepared that an old copy of
something might exist, so plain "mkdir" does not work, but "mkdir -p"
is good.