cpu/cortexm_common: remove breakpoint from hard_fault_handler #17781
Conversation
This file contains 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
The hard fault handler would normally call core_panic() which in turn calls ps() - this already helps debugging a lot of crashes caused by a thread stack overflow. With the breakpoint in place, the code will not advance to this, leaving users unknown of this feature in the dark. On top, the breakpoint is not very helpful if thread stacks are already corrupted. Let's just drop it for simplicity's sake - it's not there for any other architectures.
github-actions
bot
added
Area: cpu
maribu
approved these changes
Jun 2, 2022
maribu
added
the
CI: ready for build
fjmolinas
added
CI: ready for build
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Contribution description
The hard fault handler would normally call
core_panic()which in turn callsps()- this already helps debugging a lot of crashes caused by a thread stack overflow.With the breakpoint in place, the code will not advance to this, leaving users unknown of this feature in the dark.
On top, the breakpoint is not very helpful if thread stacks are already corrupted.
Let's just drop it for simplicity's sake - it's not there for any other architectures.
Testing procedure
Issues/PRs references