-
Notifications
You must be signed in to change notification settings - Fork 3k
mbed_error.c: Better HW fault exceptions and stack dump #11332
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
19 commits
Select commit
Hold shift + click to select a range
9af7ea5
The candidate code to enable correct crash report for HW fault crashes.
andrewc-arm d69dc49
Fixed astyle failures on handle_error().
andrewc-arm 57ed4f3
Removed #warning of non-Cortex-M. Minor comment adjustment.
andrewc-arm 50daa7e
platform.stack-dump-enabled feature is added.
andrewc-arm 2487461
Now stack dump is done correctly to the other way around.
andrewc-arm 575bd31
print_error_report: Don't care about osRtxStackFillPattern and dump w…
andrewc-arm 835a763
print_error_report: Paying extra caution on address alignment.
andrewc-arm 5671416
handle_error: Now supports HW exception from handler mode.
andrewc-arm db1e2d3
astyle to mbed_error.c
andrewc-arm d83bbd9
Reverted back the astylerc.
andrewc-arm 7dc5317
mbed_error.c: Now we can stack dump on all possible threads.
andrewc-arm 5258768
The stack dump of the major should be moved up.
andrewc-arm 95d2eb8
platform: stack-dump-enabled default value to false.
andrewc-arm da2f8e5
mbed_error.c: reducing RTX restriction.
andrewc-arm 0da589e
mbed_error.c: handler mode failures will dump MSP/PSP stacks.
andrewc-arm 76353d5
mbed_error.c: now dumping MSP/PSP stacks correctly.
andrewc-arm a769b7d
mbed_error.c: Fixed compile errors with non-RTX targets.
andrewc-arm bd9ec8b
mbed_error.c: fixed the dump core function's bug of possible stack ov…
andrewc-arm c257c5f
mbed_error.c: Fixed another bug of possible stack overflow.
andrewc-arm File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Thread current SP" would actually be
PSP
.SP_reg
will be either thread SP (PSP) if the exception happened in thread mode, or main SP (MSP) if the exception happened in handler mode. Second case is less likely but possible.I think you want
PSP
specifically here, as you are going to show it as part of the "current thread" line, next to the pointer for the thread base, as if intending to compare them.(Although it doesn't matter that much, as the fault handler should have printed all of SP, MSP and PSP anyway before entering us, right?)
Not sure the warning is the way to go - we have no portable non-M fault handler, so how could any using a Cortex-A "implement a non Cortex-M handler" in this file to silence it? I would just let it use the existing code, and skip the warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kjbracey-arm
Please note that there is an adjustment of PSP/MSP on this assembly code. It looks like the assembly code is adjusting the PSP/MSP value offset caused by calling
Fault_Handler
. I experimented with gdb and made sure thatSP_reg
value is the exact same withSP
register value just before the crash. If you observe teraterm_20190826.1656.log, you can see thatSP
andPSP
are different.Yes. We print all the context as shown above. And we print this mode information as well.
OK. I removed the warning in bdfef3f.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, that complicates a bit. So
SP
is a better value for "thread SP" thanPSP
if the exception was from thread mode. But if the exception was from handler mode, thenSP
is a better value for "handler SP" thanMSP
.Then if you're looking for "thread stack pointer" specifically, then you'd want to take
SP
if from exception was from thread mode, orPSP
if from handler mode. So you need to look at theSPSEL
bit of the exception return value.(I've been around all this stuff working on exception handling for pyOCD, which has to do the same sort of reconstruction logic, trying to cover all cases).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kjbracey-arm
Yes. I believe
SP
is the better value in both cases. If that's what you meant.In case of thread mode,
PSP
is provided as a source toSP
via except.S#L112. In case of handler mode,MSP
is provided as source toSP
via except.S#L107. Our assembly already checksEXC_RETURN
from except.S#L110.For stack dump feature upcoming, I will check the mode and dump the right PSP/MSP. For this PR, I believe providing
SP
as it is a good choice.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So in that case
SP
is not a thread stack pointer at all. If you're not able to do adaptive behaviour here, then a fixed choice ofSP
is better to get precision for the common case of exception in thread mode, so it's the 1 to go for, even though it's worse for the rare case of exception in handler mode.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I understand your point. You mean this printout
should also be changed to correctly show the handler stack instead of the thread stack. I will test with handler mode crashes and see if I can improve today.
@0xc0170 , please hold off merging. 😊
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current thread information is still useful in that case.
With the thread dumping info on (I'm not sure why it isn't by default), it would be the missing (and most important piece) of the full thread dump. The thread information extracted from the OS is only up-to-date for the non-active threads - we have to get the current thread's from the registers.
But if the crash is actually in handler mode, it could either be due to a random interrupt thing, totally unconnected to the current thread, or it could be due to something the current thread did (maybe enabling interrupts at a bad time, or some bug in a supervisor call to RTOS).
So it would make sense to show both current thread and handler mode info when crashing in handler mode. Either or both could be important.
Again - look at pyOCD, and this is basically how it displays info with its thread awareness.
It shows:
MSPPSP).So the handler mode stack appears whenever stopped in handler mode, else you don't see it and only see threads.
This then ties in with pyocd/pyOCD#430, which I really should get merged, which makes it show the aborting thread by default when stopping in the fault handler - at present, it shows you as having "SIGSEGV at fault handler", rather than the more logical "SIGSEGV at main thread location". The first is technically true at a hardware level, because it has entered the fault handler by the time the debugger gets there, but it's not the way that signals are supposed to be reported in GDB. (It's not as if your thing here is going to say hard fault at fault handler, is it?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kjbracey-arm
Please review the original description of this request.
Now with above two configs set to true, Mbed-OS will print the whole stack including the
handler mode
's stack.Also, note how
handler mode
's printout is cleaned up like this.There is no thread id in handler and there is no entry. Or if you know, please let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want a handler pseudo-thread (and that's a reasonable way to present it), it should be in addition to the current OS thread, rather than replacing it (like pyOCD). If I read the current code correctly, if I pass a bad pointer to
osMutexLock
, then we could enter the SVC handler, then hard fault inside it, and we wouldn't see the current thread that did that. We'd see "handler" and all other threads, and no backtrace showing the mutex lock at all.(You should be able to test literally that scenario - do something like
osMutexLock((osMutexId_t) 0xDEADDEAD)
).In the handler crash scenario, we don't know whether it's the handler's fault (eg bad interrupt handler) or the current thread's fault, like that mutex lock. So we should try to get both backtraces.