aboutsummaryrefslogtreecommitdiff
path: root/gdb/regformats
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2019-07-23 15:15:20 +0200
committerTom de Vries <tdevries@suse.de>2019-07-23 15:15:20 +0200
commit9a618ef61593ea5103aaf17bbe968bf552aa3de0 (patch)
treec84ca57bb93cd2e89c16555a28c4337d3b7904a8 /gdb/regformats
parent40eadf04ff1f0eaec82dc911cf079555cdbb03d0 (diff)
downloadgdb-9a618ef61593ea5103aaf17bbe968bf552aa3de0.zip
gdb-9a618ef61593ea5103aaf17bbe968bf552aa3de0.tar.gz
gdb-9a618ef61593ea5103aaf17bbe968bf552aa3de0.tar.bz2
[gdb/testsuite] Add missing initial prompt read in multidictionary.exp
When running multidictionary.exp in conjunction with: ... $ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1)) ... we get: ... Running gdb/testsuite/gdb.dwarf2/multidictionary.exp ... ERROR: Couldn't load multidictionary into gdb. === gdb Summary === nr of unresolved testcases 1 ... The multidictionary test-case needs -readnow, and achieves this using: ... gdb_spawn_with_cmdline_opts "-readnow" gdb_load ... but the initial gdb prompt is not read. Usually, the following gdb_load command accidentally consumes that initial prompt (at the gdb_expect for the kill command in gdb_file_cmd). But under high load, that doesn't happen and we run into the error. Fix this by consuming the initial gdb prompt after spawning gdb. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-07-23 Tom de Vries <tdevries@suse.de> PR testsuite/24842 * gdb.dwarf2/multidictionary.exp: Consume initial prompt after gdb_spawn_with_cmdline_opts.
Diffstat (limited to 'gdb/regformats')
0 files changed, 0 insertions, 0 deletions