aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.mi/mi-console.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@ericsson.com>2016-05-18 10:13:12 -0400
committerSimon Marchi <simon.marchi@ericsson.com>2016-05-18 10:13:16 -0400
commit9e8f9b05add4517189d7724ff3ed7c16f7b04daf (patch)
treee3a9740721001f6610f2667959a88b4f868cf2e3 /gdb/testsuite/gdb.mi/mi-console.c
parent28addb40c77db5a5873172b62b6b7b43e5e05014 (diff)
downloadgdb-9e8f9b05add4517189d7724ff3ed7c16f7b04daf.zip
gdb-9e8f9b05add4517189d7724ff3ed7c16f7b04daf.tar.gz
gdb-9e8f9b05add4517189d7724ff3ed7c16f7b04daf.tar.bz2
Add mi-threads-interrupt.exp test (PR 20039)
Add a new test for PR 20039. The test spawns new threads, then tries to interrupt, continue, and interrupt again. This use case was fixed by commit 5fe966540d6b748f825774868463003700f0c878 in master, but gdb 7.11 is affected (so if you try it on the gdb-7.11-branch right now, the test will fail). New in v2, the test now handles mi-async on mode properly. The failure was specific to mi-async off, but I don't think it's bad to test the same thing under async on mode. I added a little hack when running in async mode to work around bug 20045. I also removed one continue/interrupt pair, as a single one was enough to trigger the problem. gdb/testsuite/ChangeLog: * gdb.mi/mi-threads-interrupt.c: New file. * gdb.mi/mi-threads-interrupt.exp: New file.
Diffstat (limited to 'gdb/testsuite/gdb.mi/mi-console.c')
0 files changed, 0 insertions, 0 deletions