On Tue, Jun 21, 2016 at 04:52:32PM -0400, Dave Anderson wrote:
>
> > Dave,
> >
> > This patch addresses all the issues that I mentioned in [1], and
> > re-factored arm64_back_trace_cmd() to make it simpler, while
> > arm64_unwind_frame() gets a bit complicated. But those changes,
> > I believe, m
Changes in v4:
* use arm64_on_irq_stack() to check whether or not we are on IRQ stack.
mistakendly used 'flags & IRQ_STACKS'.
* fix a bug at critical timing around switching stacks in arm64_unwind_frame().
We need to take are of a possibility that we get back to process stack,
but fp still po
For example, crash_kexec() calls several sub functions.
So even if we find some address, as a saved lr, which belongs to this
function, it may not be the *last* stackframe.
For our purpose of backtracing, it is not necessary to find the last
frame, but the saved frame pointer should be sane for la
On arm64, the link register (LR) holds a return address, which is the one
just after a branch instruction. So using a saved lr as PC for backtracing
might cause some confusion.
For example, in kernel/entry.S,
work_resched:
...
bl schedule
ret_to_user:
...
The current code shows "ret_o
Signed-off-by: AKASHI Takahiro
---
arm64.c | 504 +++-
defs.h | 6 +
2 files changed, 344 insertions(+), 166 deletions(-)
diff --git a/arm64.c b/arm64.c
index 06676d1..4f85772 100644
--- a/arm64.c
+++ b/arm64.c
@@ -42,18 +42,18 @@ st
- Original Message -
> Dave,
>
> This patch addresses all the issues that I mentioned in [1], and
> re-factored arm64_back_trace_cmd() to make it simpler, while
> arm64_unwind_frame() gets a bit complicated. But those changes,
> I believe, make the code more readable and easily maintaina
