gdb/testsuite: also compile foll-exec.exp as C++

For a long time, Fedora GDB has carried a test that performs some
basic testing that GDB can handle 'catch exec' related commands for a
C++ executable.

The exact motivation for this test has been lost in the mists of time,
but looking at the test script, the concern seems to be that GDB would
have problems inserting C++ related internal breakpoints if a non C++
process is execd from a C++ one.

There's no actual GDB fix associated with the Fedora test.  This
usually means that the issue was fixed upstream long ago.  This patch
does seem to date from around 2010ish (or maybe earlier).

Having a look through the upstream tests, I cannot see anything that
covers this sort of thing (C++ to C exec calls), and I figure it
cannot hurt to have some additional testing in this area, and so I
wrote this patch.

I've taken the existing foll-exec.exp test, which compiles a C
executable and then execs a different C executable, and split it into
two copies.

We now have foll-exec-c.exp and foll-exec-c++.exp.  These tests
compile a C and C++ executable respectively.  Then within each of
these scripts both a C and C++ helper application is built, which can
then be execd from the main test executable.

And so, we now cover 4 cases, the initial executable can be C or C++,
and the execd process can be C or C++.

As expected, everything passes.  This is just increasing test
coverage.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

1 files changed, 19 insertions, 10 deletions

diff --git a/gdb/testsuite/gdb.base/foll-exec.c b/gdb/testsuite/gdb.base/foll-exec.c
index a1c9b70..548f045 100644
--- a/gdb/testsuite/gdb.base/foll-exec.c
+++ b/gdb/testsuite/gdb.base/foll-exec.c
@@ -19,7 +19,8 @@
 #include <stdlib.h>
 #include <unistd.h>
 #include <string.h>
-
+#include <libgen.h>
+#include <assert.h>
 #include <limits.h>
 
 int global_i = 100;
@@ -29,15 +30,23 @@ int main (int argc, char ** argv)
   int local_j = global_i + 1;
   int local_k = local_j + 1;
   char prog[PATH_MAX];
-  int len;
+  size_t len = PATH_MAX - 1;
+
+  printf ("foll-exec is about to execlp(%s)...\n", EXECD_PROG);
+
+  prog [len] = '\0';
+
+  strncpy (prog, dirname (argv[0]), len);
+  len -= strlen (prog);
+  assert (len > 0);
 
-  printf ("foll-exec is about to execlp(execd-prog)...\n");
+  strncat (prog, "/", len);
+  len -= 1;
+  assert (len > 0);
 
-  strcpy (prog, argv[0]);
-  len = strlen (prog);
-  /* Replace "foll-exec" with "execd-prog".  */
-  memcpy (prog + len - 9, "execd-prog", 10);
-  prog[len + 1] = 0;
+  strncat (prog, EXECD_PROG, len);
+  len -= strlen (EXECD_PROG);
+  assert (len > 0);
 
   /* In the following function call, maximum line length exceed the limit 80.
      This is intentional and required for clang compiler such that complete
@@ -45,7 +54,7 @@ int main (int argc, char ** argv)
      multi-line.  */
   execlp (prog, /* tbreak-execlp */ prog, "execlp arg1 from foll-exec", (char *) 0);
 
-  printf ("foll-exec is about to execl(execd-prog)...\n");
+  printf ("foll-exec is about to execl(%s)...\n", EXECD_PROG);
 
   /* In the following function call, maximum line length exceed the limit 80.
      This is intentional and required for clang compiler such that complete
@@ -61,7 +70,7 @@ int main (int argc, char ** argv)
 
     argv[0] = prog;
 
-    printf ("foll-exec is about to execv(execd-prog)...\n");
+    printf ("foll-exec is about to execv(%s)...\n", EXECD_PROG);
 
     execv (prog, argv); /* tbreak-execv */
   }