gdb/testsuite: use libtool to launch selftests

When building GDB on Cygwin, gdb/gdb.exe is a libtool wrapper (which
happens to be a PE executable).  The real executable is at
gdb/.libs/gdb.exe.  The "does gdb have debug info test" that
_selftest_setup does is bogus, because it loads the libtool wrapper
(which doesn't have debug info), doesn't see any debug info, and thus
the test is skipped.

The "correct" way to deal with libtool wrappers is to run the shell
command you want to run under `libtool --mode=execute`.  That will
replace any path resembling to a libtool wrapper with the real
executable path.  But it will also add to the environment the library
paths necessary for this executable to find the libraries it needs.

Therefore, modify the `do_self_tests` proc to:

  - run the top-level GDB commands under `libtool --mode=execute`
  - pass the path to the inferior GDB on the command-line of the
    top-level, so that it gets replaced with the real executable's path

However, the "file" command was previously used to detect the presence
of debug info in the GDB executable.  It's not easy to implement this
check when loading the executable directly on the command line. So, add
a separate proc, _selftest_check_executable_debug_info, that spawns a
temporary GDB and does the debug info check through the file command.
This proc uses libtool to obtain the path to the real executable.

When building, we use the bundled libtool.m4 at the top of the tree.
This means that the libtool system package, and therefore the libtool
binary, might not be available.  Check for the presence of the libtool
binary first, and only do the conversion if it is found.  If it is not
found, the test should still work on platforms that don't require the
conversion.

With this commit, the test runs on Cygwin, even though there are
failures later.

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

0 files changed, 0 insertions, 0 deletions