Re: [rfc/testsuite] editor.exp: new test script for "edit" command

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

Daniel Jacobowitz writes:
>   - GDB's testsuite assumes that host and build are the same.
>     So I don't know if the consistency is worth it unless someone
>     cares about separating them.

I looked into this.  Let me sort my thoughts.

build  == machine where dejagnu is running.
host   == machine where gdb and gcc is running.
target == machine where test program (test.exe) is running

Dejagnu supports separate build and host machines

In default_target_compile, if host is remote from build, then
default_target_compile calls remote_download to copy the test program
source code (test.c) from build to host.  default_target_compile also
calls remote_upload to copy a.out back from host to build.

If the test.c includes test.h, then test.exp has to download this file
onto the host by hand.

gdb.base/list.exp actually does this:

  remote_download host ${srcdir}/${subdir}/list0.h list0.h
  ...
  remote_exec build "rm -f list0.h"

However, all these test scripts neglect to download their *.h files:

  gdb.arch/i386-sse.exp
  gdb.base/lineinc.exp
  gdb.base/macscp.exp
  gdb.base/overlays.exp
  gdb.base/shlib-call.exp
  gdb.cp/m-static.exp
  gdb.cp/rtti.exp
  gdb.hp/gdb.compat/xdb2.exp
  gdb.hp/gdb.objdbg/objdbg01.exp
  gdb.hp/gdb.objdbg/objdbg04.exp
  gdb.stabs/exclfwd.exp

There are other issues with separate build and host, like core files.
gdb creates them on the host machine, but then gcore.exp expects to see
them on the build machine.

I don't think there's much of a demand for the gdb testsuite to support
separate build and host machines.  So I'm going to propose a policy
change, in the form of a documentation patch to the 'Testsuite' section
of gdbint.texinfo, that the gdb test suite does not support separate
build and host machines.  (Of course we support separate host/build and
target machines!)

Michael C