]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
[gdb/testsuite] Fix timeout in gdb.mi/mi-multi-commands.exp
authorTom de Vries <tdevries@suse.de>
Mon, 23 Sep 2024 05:45:54 +0000 (07:45 +0200)
committerTom de Vries <tdevries@suse.de>
Mon, 23 Sep 2024 05:45:54 +0000 (07:45 +0200)
commit59c9bc5fb6c25a621a132623b41c5555c610f92d
tree218b168740e8008e2098d6e2fa3afee7b5b0c4fe
parentf844c8f242d3621da7e978b65cb1f486347d54c6
[gdb/testsuite] Fix timeout in gdb.mi/mi-multi-commands.exp

On aarch64-linux, with test-case gdb.mi/mi-multi-commands.exp once in a while
I run into (edited for readability):
...
(gdb) ^M
<LOTS-OF-SPACES>-data-evaluate-expression $a^M
-data-evaluate-^done,value="\"FIRST COMMAND\""^M
expression $b(gdb) ^M
^M
^done,value="\"TEST COMPLETE\""^M
(gdb) ^M
PASS: $exp: args=: look for first command output, command length 236
FAIL: $exp: args=: look for second command output, command length 236 (timeout)
...

This is more likely to trigger when running the test-case using
taskset -c <cpu> (where in a big.little setup we pick a little cpu).

The setup here is that the test-case issues these two commands at once:
...
-data-evaluate-expression $a
-data-evaluate-expression $b
...
where the length of the first command is artificially increased by prefixing
it with spaces, show as <LOTS-OF-SPACES> above.

What happens is that gdb, after parsing the first command, executes it.
Then the output of the first command intermixes with the echoing of the second
command, which produces this line containing the first prompt:
...
expression $b(gdb) ^M
...
which doesn't match the \r\n prefix of the regexp supposed to consume the
first prompt:
...
           -re "\r\n$mi_gdb_prompt" {
...

Fix this by dropping the \r\n prefix.

Tested on aarch64-linux.

PR testsuite/29781
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29781
gdb/testsuite/gdb.mi/mi-multi-commands.exp