From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [committed][gdb/testsuite] Fix timeout in gdb.mi/user-selected-context-sync.exp with gcc-11
Date: Thu, 10 Jun 2021 13:38:26 +0200 [thread overview]
Message-ID: <20210610113824.GA31858@delia> (raw)
Hi,
When running test-case gdb.mi/user-selected-context-sync.exp with gcc-11, we
get:
...
continue^M
Continuing.^M
FAIL: gdb.mi/user-selected-context-sync.exp: mode=all-stop: test_setup: \
inferior 1: continue to breakpoint: continue thread 1.2 to infinite \
loop breakpoint (timeout)
...
This is a regression since commit aa33ea68330 "testsuite, mi: avoid a clang
bug in 'user-selected-context-sync.exp'", which fixes a similar hang when
using clang.
The source before the commit contains:
...
while (1);
...
and after the commit:
...
int spin = 1;
while (spin);
...
[ FWIW, I've filed a PR gcc/101011 - Inconsistent debug info for "while (1);"
to mention that gcc-11 has different behaviour for these two loops. ]
The problem is that:
- the test-case expects the behaviour that a breakpoint set
on the while line will trigger on every iteration, and
- that is not guaranteed by either version of the loop.
Fix this by using a while loop with a dummy body:
...
volatile int dummy = 0;
while (1)
dummy = !dummy;
...
and setting the breakpoint in the body.
Tested on x86_64-linux with clang 10.0.1, gcc-4.8, gcc 7.5.0 and gcc 11.1.1.
Committed to trunk.
Thanks,
- Tom
[gdb/testsuite] Fix timeout in gdb.mi/user-selected-context-sync.exp with gcc-11
gdb/testsuite/ChangeLog:
2021-06-10 Tom de Vries <tdevries@suse.de>
* gdb.mi/user-selected-context-sync.c (child_sub_function, main):
Rewrite while (1) using dummy loop body.
---
gdb/testsuite/gdb.mi/user-selected-context-sync.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gdb/testsuite/gdb.mi/user-selected-context-sync.c b/gdb/testsuite/gdb.mi/user-selected-context-sync.c
index 9818f30277f..ebb55f87e2c 100644
--- a/gdb/testsuite/gdb.mi/user-selected-context-sync.c
+++ b/gdb/testsuite/gdb.mi/user-selected-context-sync.c
@@ -27,10 +27,10 @@ static pthread_barrier_t barrier;
static void
child_sub_function (void)
{
- /* Deliberately spin on a variable instead of plain 'while (1)' to
- avoid the Clang bug https://bugs.llvm.org/show_bug.cgi?id=49614. */
- int spin = 1;
- while (spin); /* thread loop line */
+ volatile int dummy = 0;
+ while (1)
+ /* Dummy loop body to allow setting breakpoint. */
+ dummy = !dummy; /* thread loop line */
}
static void *
@@ -60,10 +60,10 @@ main (void)
pthread_barrier_wait (&barrier);
- /* Deliberately spin on a variable instead of plain 'while (1)' to
- avoid the Clang bug https://bugs.llvm.org/show_bug.cgi?id=49614. */
- int spin = 1;
- while (spin); /* main break line */
+ volatile int dummy = 0;
+ while (1)
+ /* Dummy loop body to allow setting breakpoint. */
+ dummy = !dummy; /* main break line */
return 0;
}
reply other threads:[~2021-06-10 11:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20210610113824.GA31858@delia \
--to=tdevries@suse.de \
--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