]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
[gdb/testsuite] Fix timeout in gdb.mi/user-selected-context-sync.exp with gcc-11
authorTom de Vries <tdevries@suse.de>
Thu, 10 Jun 2021 11:38:03 +0000 (13:38 +0200)
committerTom de Vries <tdevries@suse.de>
Thu, 10 Jun 2021 11:38:03 +0000 (13:38 +0200)
commit6179e5f1d8d54e10a128e4de9c96ecda79e788bf
treede1ffd7b5264044a21c0a2a7b5c3097052514251
parent1db66fb653995e45fa55d44bddf25bdf55efb46a
[gdb/testsuite] Fix timeout in gdb.mi/user-selected-context-sync.exp with gcc-11

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.

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/ChangeLog
gdb/testsuite/gdb.mi/user-selected-context-sync.c