hitHuang commented on PR #19439:
URL: https://github.com/apache/nuttx/pull/19439#issuecomment-4986841008
For a kernel thread, there's no question that dumpstack should return the
kernel-mode backtrace. But for a user thread — when it has trapped into the
kernel (e.g. blocked inside a syscall) — do we expect dumpstack to return the
kernel-stack backtrace, or the user-stack
backtrace?
This PR currently follows the existing design in riscv_backtrace():
regardless of whether the user thread has switched onto a separate kernel
stack, up_backtrace() always aims to reconstruct the user-mode call chain —
when it has trapped into the kernel stack, it uses
xcp.ustkptr (the user-mode SP recorded at the moment of the trap) as an
anchor to "bridge" the walk back onto the user stack and continue from there
(if I'm understanding this correctly). This fix only corrects
implementation-level bugs on top of that existing approach; it
doesn't change the direction itself.
I'm not fully confident that "always walk back to the user stack" is the
right/ideal design, and would welcome the community's input either way.
Regardless of which direction is correct, though, it's clear that the current
mainline implementation has real bugs — not just on
RISC-V, but also in the arm64 implementation for the CONFIG_BUILD_KERNEL
case.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
