gdb/testsuite: do not copy gdb executable in self tests

In the ROCm-GDB testing process, we hit a problem that is a combination
of these 3 factors:

1. In the downstream ROCm-GDB packages, the gdb executable is built with
   a relative RUNPATH:

       0x000000000000001d (RUNPATH)            Library runpath: [${ORIGIN}/../lib]

   This is done so that the installation is relocatable (the whole ROCm
   directory can be copied around) and things still work.  For instance,
   the rocgdb executable needs to be able to find the libraries it
   needs, such as `librocm-dbgapi.so.0`.  The relative runpath allows
   that.

2. For testing, we run the testsuite against the gdb executable
   installed from one of those packages.  It is possible to ./configure
   the testsuite directory on its own, and then do:

       $ make check RUNTESTFLAGS="GDB=/opt/rocm/bin/rocgdb"

3. The selftests (such as gdb.gdb/selftest.exp) copy the GDB under test
   to the standard output directory, before trying to debug it.

The problem is that the gdb executable under test that has been copied
can't find the libraries it needs.

With this patch, I propose that we don't copy the gdb executable, but
debug it in place instead.  The comment removed in this patch says "in
case this OS doesn't like to edit its own text space", and has been
there since forever in some form.  But it's not clear if there is a host
OS (where we intend to run this test) that needs this nowadays.  I would
bet that there isn't.  If there is in fact a GDB host OS (where we
intend to run this test) that needs it, we can reinstate the copying,
but as an opt-in operation.

Another situation where this change helps is on Windows, where
gdb/gdb.exe is a libtool wrapper (the real executable is at
gdb/.libs/gdb.exe).  Copying gdb/gdb.exe doesn't accomplish anything
useful.  The next patch does further changes to account for the libtool
wrapper case.

I tested on Linux and Cygwin, more testing would be welcome.

Change-Id: Id4148517d4fc4ecdd49f099c12003e3d16c6a93d
Reviewed-By: Keith Seitz <keiths@redhat.com>

0 files changed, 0 insertions, 0 deletions