[PATCH] gdb.base/execl-update-breakpoints.exp: Don't execl forever

[PATCH] gdb.base/execl-update-breakpoints.exp: Don't execl forever

[Pedro Alves]

execl-update-breakpoints.c is compiled as both
execl-update-breakpoints1 and execl-update-breakpoints2.

execl-update-breakpoints1 checks to see if the last character in its
filename is '1', and if so, replace it with '2' and execl the result.

On Windows, this fails to take into account that the filename may have
an ".exe" extension.  The result is that the execl-update-breakpoints1
executable execs itself forever.

This patch fixes it by taking the .exe extension into account.

(Note that neither native Windows nor Cygwin support following execs,
and maybe the testcase will eventually be skipped there, but even
then, if someone enables follow-exec testing there, we'd want it to
handle the .exe extension, so I think it's better to adjust the
testcase than not.)

Now, on e.g. GNU/Linux, if you run execl-update-breakpoints1 manually,
you'll see that it also execs forever, but this time, what happens is
that execl-update-breakpoints1 execs execl-update-breakpoints2, and
then it's execl-update-breakpoints2 that execs itself forever.  There
is no reason for execl-update-breakpoints2 to exec.  It's just that
the testcase is assuming that the process is killed when the testcase
is over.  It's just cleaner if execl-update-breakpoints1 execs
execl-update-breakpoints2, and then execl-update-breakpoints2 just
cleanly exits.  The patch does that too.

And then, the test program should really be erroring out if neither
'1' nor '2' is found at the tail of the executable.  Done too.

Change-Id: Id88830cd8dff2c63dd69b827d4ba79743aa9ebca
---
 .../gdb.base/execl-update-breakpoints.c       | 22 ++++++++++++++-----
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/gdb.base/execl-update-breakpoints.c b/gdb/testsuite/gdb.base/execl-update-breakpoints.c
index e71efd097b1..c781b34f522 100644
--- a/gdb/testsuite/gdb.base/execl-update-breakpoints.c
+++ b/gdb/testsuite/gdb.base/execl-update-breakpoints.c
@@ -34,11 +34,21 @@ main (int argc, char **argv)
   len = strlen (argv[0]);
   bin = malloc (len + 1);
   memcpy (bin, argv[0], len + 1);
-  if (bin[len - 1] == '1')
-    bin[len - 1] = '2';
 
-  execl (bin, bin, (char *) NULL);
-  perror ("execl failed");
-  some_function ();
-  exit (1);
+  /* Account for the extension on Windows.  */
+  if (len > 4 && strcmp (bin + len - 4, ".exe") == 0)
+    len -= 4;
+
+  if (bin[len - 1] == '1')
+    {
+      bin[len - 1] = '2';
+      execl (bin, bin, (char *) NULL);
+      perror ("execl failed");
+      some_function ();
+      exit (1);
+    }
+  else if (bin[len - 1] == '2')
+    exit (0);
+  else
+    exit (1);
 }

base-commit: 4c4e1dd5a02c1a03e7eb408987404ffd1adfd1e4
-- 
2.54.0

Re: [PATCH] gdb.base/execl-update-breakpoints.exp: Don't execl forever

[Simon Marchi]

On 2026-07-09 13:58, Pedro Alves wrote:
> execl-update-breakpoints.c is compiled as both
> execl-update-breakpoints1 and execl-update-breakpoints2.
> 
> execl-update-breakpoints1 checks to see if the last character in its
> filename is '1', and if so, replace it with '2' and execl the result.
> 
> On Windows, this fails to take into account that the filename may have
> an ".exe" extension.  The result is that the execl-update-breakpoints1
> executable execs itself forever.
> 
> This patch fixes it by taking the .exe extension into account.
> 
> (Note that neither native Windows nor Cygwin support following execs,
> and maybe the testcase will eventually be skipped there, but even
> then, if someone enables follow-exec testing there, we'd want it to
> handle the .exe extension, so I think it's better to adjust the
> testcase than not.)
> 
> Now, on e.g. GNU/Linux, if you run execl-update-breakpoints1 manually,
> you'll see that it also execs forever, but this time, what happens is
> that execl-update-breakpoints1 execs execl-update-breakpoints2, and
> then it's execl-update-breakpoints2 that execs itself forever.  There
> is no reason for execl-update-breakpoints2 to exec.  It's just that
> the testcase is assuming that the process is killed when the testcase
> is over.  It's just cleaner if execl-update-breakpoints1 execs
> execl-update-breakpoints2, and then execl-update-breakpoints2 just
> cleanly exits.  The patch does that too.
> 
> And then, the test program should really be erroring out if neither
> '1' nor '2' is found at the tail of the executable.  Done too.

So the goal is just to have one exec and then exit?  Could we just pass
a regular argument (argv[1]) instead of tweaking argv[0]?  Like the
process could be launched without argument at first, and then it execs
itself with an argument, and just the presence of that argument would be
a flag to say "don't re-exec, just exit".

Simon

Re: [PATCH] gdb.base/execl-update-breakpoints.exp: Don't execl forever

[Pedro Alves]

On 2026-07-09 19:14, Simon Marchi wrote:

> So the goal is just to have one exec and then exit?  Could we just pass
> a regular argument (argv[1]) instead of tweaking argv[0]?  Like the
> process could be launched without argument at first, and then it execs
> itself with an argument, and just the presence of that argument would be
> a flag to say "don't re-exec, just exit".

It's not about the exec event, it has to be two separate programs:

 # Build two copies of the program, each linked at a different address.
 # The address of "main" in the first binary should end up being an
 # unmapped address in the second binary.

Re: [PATCH] gdb.base/execl-update-breakpoints.exp: Don't execl forever

[Simon Marchi]

On 2026-07-09 14:52, Pedro Alves wrote:
> On 2026-07-09 19:14, Simon Marchi wrote:
> 
>> So the goal is just to have one exec and then exit?  Could we just pass
>> a regular argument (argv[1]) instead of tweaking argv[0]?  Like the
>> process could be launched without argument at first, and then it execs
>> itself with an argument, and just the presence of that argument would be
>> a flag to say "don't re-exec, just exit".
> 
> It's not about the exec event, it has to be two separate programs:
> 
>  # Build two copies of the program, each linked at a different address.
>  # The address of "main" in the first binary should end up being an
>  # unmapped address in the second binary.

Ah ok I see, same source but two executables.  LGTM then.

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

Simon