Add FreeRTOS integration #21
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
Okay, I take that back. The debugger running in abort mode is actually critical because it automatically suppresses all hardware breakpoints. The reason a single step waits until the debug monitor returns to user code before "working" is because the debugger runs in abort mode. |
When a single step is pending, trying to resume the scheduler would cause the step to fire in an unexpected location. Bypassing the preemptive scheduler behavior makes the single more predictable, and also fixes an issue where it'd trigger directly in the debug restore code.
GDB will try to skip bkpt instructions if they are reported as software breakpoints and it doesn't know about them, so avoid that by reporting them as SIGTRAPs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements the GDB multithreading capabilities when building for freertos, and also tries to improve some of the thread safety so that FreeRTOS's task state save/restore mechanism doesn't corrupt the debugger state.
FreeRTOS context switching always assumes that user code is running in System mode: when a context switch happens via an interrupt or yield, it saves the registers from that mode. This assumption is broken when an abort happens, because the CPU switches to Abort mode. Since abort mode has its own version of the link register and stack pointer, a context switch out of the debugger would save and restore the wrong registers and also not preserve the Abort mode status.
The best solution here is probably to run the debugger in System mode like FreeRTOS expects - there's not really any huge downside to that after we've saved the previous System mode context, but we'd need to add a bit of assembly to the abort handler overlay to make the switch. We'd also want to pause the scheduler entirely so that no other tasks are running during while the debug monitor is active. (Turning the scheduler back on at the end is an explicit yield, so System mode is still necessary here.)
I'm also a little worried about stack overflow checking since we're using a different stack - we might have to switch back to the paused task's stack temporarily when resuming.