-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
coredump: ARM: Ensure sp in dump is set as gdb expects #79622
Merged
Merged
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
zephyrbot
requested review from
bbolen,
carlocaione,
galak,
ithinuel,
MaureenHelm,
microbuilder and
stephanosio
October 9, 2024 16:58
Re-submitting #73189 with a fix for the regression |
mrkhldn
force-pushed
the
coredump_arm_sp
branch
from
October 9, 2024 17:33
6e3e0f5
to
b6530e5
Compare
Gdb is typically able to reconstruct the first two frames of the failing stack using the "pc" and "lr" registers. After that, (if the frame pointer is omitted) it appears to need the stack pointer (sp register) to point to the top of the stack before a fatal error occurred. The ARM Cortex-M processors push registers r0-r3, r12, LR, {possibly FPU registers}, PC, SPSR onto the stack before entering the exception handler. We adjust the stack pointer back to the point before these registers were pushed for preservation in the dump. During k_oops/k_panic, the sp wasn't stored in the core dump at all. Apply similar logic to store it when failures occur in that path. Signed-off-by: Mark Holden <[email protected]>
mrkhldn
force-pushed
the
coredump_arm_sp
branch
from
October 9, 2024 18:29
b6530e5
to
b8839fb
Compare
ycsin
approved these changes
Oct 10, 2024
@ithinuel, thanks for approving the previous attempt at this fix. Can you take a quick look at this resubmission, with the build fix? |
ping @ithinuel @carlocaione |
stephanosio
approved these changes
Nov 5, 2024
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.
Not seeing anything obviously wrong with it.
ithinuel
approved these changes
Nov 6, 2024
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.
Gdb is typically able to reconstruct the first two frames of the failing stack using the "pc" and "lr" registers. After that, (if the frame pointer is omitted) it appears to need the stack pointer (sp register) to point to the top of the stack before a fatal error occurred.
The ARM Cortex-M processors push registers r0-r3, r12, LR, {possibly FPU registers}, PC, SPSR onto the stack before entering the exception handler. We adjust the stack pointer back to the point before these registers were pushed for preservation in the dump.
During k_oops/k_panic, the sp wasn't stored in the core dump at all. Apply similar logic to store it when failures occur in that path.
Fixes #78788