From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Subject: [PATCH] gdb.base/execl-update-breakpoints.exp: Don't execl forever
Date: Thu, 9 Jul 2026 18:58:04 +0100 [thread overview]
Message-ID: <20260709175804.434105-1-pedro@palves.net> (raw)
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
next reply other threads:[~2026-07-09 17:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 17:58 Pedro Alves [this message]
2026-07-09 18:14 ` Simon Marchi
2026-07-09 18:52 ` Pedro Alves
2026-07-09 19:41 ` Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260709175804.434105-1-pedro@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox