aboutsummaryrefslogtreecommitdiff
path: root/gdb/xml-support.c
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2021-06-10 13:38:03 +0200
committerTom de Vries <tdevries@suse.de>2021-06-10 13:38:03 +0200
commit6179e5f1d8d54e10a128e4de9c96ecda79e788bf (patch)
treede1ffd7b5264044a21c0a2a7b5c3097052514251 /gdb/xml-support.c
parent1db66fb653995e45fa55d44bddf25bdf55efb46a (diff)
downloadgdb-6179e5f1d8d54e10a128e4de9c96ecda79e788bf.zip
gdb-6179e5f1d8d54e10a128e4de9c96ecda79e788bf.tar.gz
gdb-6179e5f1d8d54e10a128e4de9c96ecda79e788bf.tar.bz2
[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.
Diffstat (limited to 'gdb/xml-support.c')
0 files changed, 0 insertions, 0 deletions