Bloody hell this is incredibly complicated... no wonder nobody can fix that bug.
FreeRTOS multi thread stepping
What is that?
[...8<...]
I never used the Enable RTOS Proxy and IIRC one needs to write some code to make that do something, like displaying RTOS tasks in "real time".
Note: I do not use Eclipse based crap, I value my time and blood pressure. So I don't know whether that "RTOS Proxy" is something else entirely. From what I can read it enables stack traces on non-running tasks. I get them for free with my monitor, pyocd, and VS-Code - no instrumenting needed, and the same should be for you. Instrumenting i needed if one wants details on the stack percentage used or on the execution times of the threads.
If you are not using the RTOS awareness at all, I imagine you cannot see the names of the threads, or see easily which one are stopped and for which reason, if you not using just the proxy you are missing out on the stack trace.
It's quite helpful: you get good stack traces for each thread/task (gdb/FreeRTOS name) instead of only the one for the currently executing task, you can step a single thread - of course this means the others may run until the step is completed - and you can inspect and modify their local variables.
Note also that gdb supports two modes for multi thread debugging, one where everything stops when one thread is interrupted (e.g. BP or Ctrl-C) one where only that single thread is stopped, while the others still run (my monitor only supports stop mode now - working on it).
gdb will negotiate with the debug server using the remote target protocol to understand its capabilities, e.g. whether it supports the extra messages to gather and set thread data, and non-stop multithread mode, if not it will just use basic protocol and single thread debugging.
The problem (I mean, feature) with Teensy is that to make it as much Arduino like as possible for programming/booting all the debugging has been crippled: JTAG/SWD is completely taken over by the extra Kinetis MCU on the board, and it is not even possible to enable the Debug Monitor exception that would allow simple gbserver-like handling via serial port (TBH: I have very few gripes with Mr Teensy, his code is usually very good, a step above 99% of the Arduino libs I happened to look at).
So I had to use a SVC call to emulate breakpoints, making sure not to interfere with FreeRTOS (which luckily just use SVC-00, and only at startup), meaning that breakpoints can only be set in RAM code (and no, I did not manage to make address translation work, probably tied to the same settings that prevent the use of debug monitor and HW breakpoints).
Moreover, to implement reasonable single instruction stepping etc. I need to calculate the length of the replaced instruction, keep track of IT instructions and so forth, quite a deep dive in the Arm architecture and instruction format(s)!
Making this pseudo debug monitor FreeRTOS aware entails also some introspection in the RTOS data structures, as gdb expect to be able to unwind the stack of all the threads it finds and needs the SP and registers of each one.
Implementing the sending and receiving of the protocol messages on a dedicated UART was in fact the simplest part of the endeavor.
Everything seems to work, with the exception that gdb gets confused by some of my answers when I try a single step on a thread that's not the active one at the moment.