[gdb/testsuite] Fix gdb.python/py-mi-cmd.exp with python 3.13
When running test-case gdb.python/py-mi-cmd.exp with python 3.13, I run into: ... Expecting: ^(-pycmd exp[^M ]+)?(.*&"Traceback \(most recent call last\):.."^M &"[^^M ]+py-mi-cmd.py[^^M ]+"^M &"[^^M ]+raise gdb.GdbError\(\).."^M &"gdb.GdbError.."^M \^error,msg="Error occurred in Python\."[^M ]+[(]gdb[)] ^M [ ]*) -pycmd exp^M &"Traceback (most recent call last):\n"^M &" File \"py-mi-cmd.py\", line 76, in invoke\n raise gdb.GdbError()\n"^M &"gdb.GdbError\n"^M ^error,msg="Error occurred in Python."^M (gdb) ^M FAIL: gdb.python/py-mi-cmd.exp: -pycmd exp (unexpected output) ... In contrast, with python 3.12 I have: ... Expecting: ^(-pycmd exp[^M ]+)?(.*&"Traceback \(most recent call last\):.."^M &"[^^M ]+py-mi-cmd.py[^^M ]+"^M &"[^^M ]+raise gdb.GdbError\(\).."^M &"gdb.GdbError.."^M \^error,msg="Error occurred in Python\."[^M ]+[(]gdb[)] ^M [ ]*) -pycmd exp^M &"Traceback (most recent call last):\n"^M &" File \"py-mi-cmd.py\", line 76, in invoke\n"^M &" raise gdb.GdbError()\n"^M &"gdb.GdbError\n"^M ^error,msg="Error occurred in Python."^M (gdb) ^M PASS: gdb.python/py-mi-cmd.exp: -pycmd exp ... To make it easier to understand what we're looking at, let's take this out of the mi interpreter context and use the cli interpreter: ... $ gdb -q -batch -ex "set trace-commands on" -x gdb.in +set python print-stack full +source py-mi-cmd.py +python pycmd1('-pycmd') +python pycmd1.invoke (pycmd1, ["exp"]) Traceback (most recent call last): File "<string>", line 1, in <module> File "py-mi-cmd.py", line 76, in invoke raise gdb.GdbError() gdb.GdbError gdb.in:4: Error in sourced command file: Error occurred in Python. ... Interestingly, this is what we're seeing with both python 3.12 and 3.13. The difference between the python versions is that: - with python 3.12 each line is printed by itself, and - with python 3.13 two particular lines are printed toghether. With the cli interpreter, that makes no difference, because the '\n' is interpreted. But with the mi interpreter, that causes a difference in output because the '\n' is not interpreted, but rather printed literally. Fix this by accepting the new output in addition to the old one. Tested on aarch64-linux. Reviewed-by:Thiago Jung Bauermann <thiago.bauermann@linaro.org> PR testsuite/31913 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31913
Loading
Please register or sign in to comment