GDB stepping from python script does not work synchronously

[Russ Butler]

When I up upgraded to a recent version of the GNU ARM Embedded toolchain, a gdb script I had stopped working correctly. I narrowed this down to synchronous single stepping in the script. Even though it was called synchronously, the command ran asynchronously and caused the next step to fail. I have attached a simple script to reproduce this. This problem started on 2016q4 release.

Versions working correctly:
gcc-arm-none-eabi-5_3-2016q1-20160330-win32.exe (GDB version 7.10.1.20160210-cvs)
gcc-arm-none-eabi-5_4-2016q2-20160622-win32.exe (GDB version 7.10.1.20160616-cvs)
gcc-arm-none-eabi-5_4-2016q3-20160926-win32.exe (GDB version 7.10.1.20160923-cvs)

Versions exhibiting this problem:
gcc-arm-none-eabi-6_2-2016q4-20161216-win32.exe (GDB version 7.12.0.20161204-git)
gcc-arm-none-eabi-6-2017-q1-update-win32.exe (GDB version 7.12.1.20170215-git)

To reproduce this problem you'll need to run a gdb server in one terminal (in this case pyOCD) and the attached gdb_script_simple.py in another as shown below.

Terminal 1:
pip install pyocd
pyocd-gdbserver -p 3334

Terminal 2:
arm-none-eabi-gdb-py.exe --command=gdb_script_simple.py

Test script output 2016q3:
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160923-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) 0x000004b0 in ?? ()
Step returned: '0x00000442 in ?? ()
'
Step returned: '0x00000446 in ?? ()
'
Step returned: '0x00000448 in ?? ()
'
Step returned: '0x0000044a in ?? ()
'
Step returned: '0x000004a8 in ?? ()
'
Stepping successful

Test script output 2016q4:
GNU gdb (GNU Tools for ARM Embedded Processors) 7.12.0.20161204-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) 0x000004a8 in ?? ()
Step returned: ''
0x000004ac in ?? ()

[Tejas Belagod (belagod-tejas)]

Hi Russ,

I can't seem to reproduce this either on Linux or Windows. On Windows I tried using the pyocd_win.exe from https://developer.mbed.org/blog/entry/pyOCD-Binary-Version/ but the stepping does not seem to proceed in either case. GDB just opens and waits for input. What am missing?

[Russ Butler (c1728p9)]

You'll need to have a board supported by pyOCD connected. To show connected boards that pyOCD recognizes you can add the '-l' flag:
pyocd-gdbserver -l
0 => FRDM-K64F [k64f] boardId => 0240000033514e45001c500585d40025e981000097969900

[Russ Butler (c1728p9)]

Issue raised by Tejas on the GDB bug tracker can be found here:
https://sourceware.org/bugzilla/show_bug.cgi?id=21698