----- Original Message -----
Dave,
When I looked at the output from "bt -f" command, I found that stack dump
starts from frame.sp in arm64_print_stackframe_entry().
Usage of stack frames on arm64 is a bit different from that on x86, and
using frame.fp is, I believe, much useful (and accurate) for crash users.
See my patch attached below.
Details:
A layout of a stack frame in a function looks like:
stack grows to lower addresses.
/|\
|
| |
new sp +------+ <---
|dyn | |
| vars | |
new fp +- - - + |
|old fp| | a function's stack frame
|old lr| |
|static| |
| vars| |
old sp +------+ <---
|dyn |
| vars |
old fp +------+
| |
* On function entry, sp is decremented down to new fp.
* and old fp and sp are saved into this stack frame.
"Static" local variables are allocated at the same time.
* Later on, "dynamic" local variables may be allocated on a stack.
But those dynamic variables are rarely used in the kernel image,
and, as a matter of fact, sp is equal to fp in almost all functions.
(not 100% though.)
* Currently, sp is determined in arm64_unwind_frame() by
sp = a callee's fp + 0x10
where 0x10 stands for a saved area for fp and sp
* As you can see, however, this calculated sp still points to the top of
callee's static local variables and doesn't match with a *real* sp.
* So, generally, dumping a stack from this calculated sp to the next frame's
sp shows "callee's static local variables", old fp and sp.
Confused?
OK, it's sinking in...
But how do you want to handle the top of all user space backtraces, i.e.,
the frame just before the user-space exception frame gets dumped? You
don't show it below, but it's kind of confusing to show a stack address
of 0.
Also, the stack dump shown before the #0 frame of active tasks is kind
of confusing. I'm not even sure it's worth showning? Or would be more
of a hack to prevent it from being displayed?
You commmented out the call to arm64_display_full_frame() in
arm64_print_exception_frame() -- is it because your patch has already
dumped it prior to the actual translated exception frame dump?
Dave
Probably you will be able to understand more easily by seeing an
example
from my vmlinux/vmcore cases:
=== crash with my patch ===
crash> bt -f 1324
PID: 1324 TASK: ffff80002018be80 CPU: 2 COMMAND: "dhry"
ffff800022f6ae08: ffff00000812ae44 (crash_save_cpu on IRQ stack)
ffff800022f6ae10: ffff800022f74e00 ffff800020107ed0
ffff800022f6ae20: 0000000000000000 ffff800020107ed0
ffff800022f6ae30: ffff000008a26800 0000000000000003
ffff800022f6ae40: 0000018800000005 0000000000000001
#0 [ffff800022f6ae50] crash_save_cpu at ffff00000812ae44
ffff800022f6ae50: ffff800022f6b010 ffff00000808e718
#1's fp #1's lr (=handle_IPI)
ffff800022f6ae60: ffff000008bce000 0000000000000002 -----
ffff800022f6ae70: ffff800022f6ae90 0000000000000000 |
ffff800022f6ae80: ffff800000000000 0000000000000000 |
ffff800022f6ae90: 0000000000000000 0000000000000000 |local variables
... | including a big
ffff800022f6afd0: 0000000000000000 0000000000000000 |"struct
elf_prsatus"
ffff800022f6afe0: ffff800022f6aff0 ffff00000808a820 |
ffff800022f6aff0: ffff800022f6b010 ffff00000808e758 |
ffff800022f6b000: ffff000008bce000 0000000000000000 -----
#1 [ffff800022f6b010] handle_IPI at ffff00000808e718
ffff800022f6b010: ffff800022f6b040 ffff0000080815f8
ffff800022f6b020: 0000000000000003 0000000000001fff
ffff800022f6b030: ffff800020107ed0 ffff000008e60c54
#2 [ffff800022f6b040] gic_handle_irq at ffff0000080815f8
ffff800022f6b040: ffff800022f6b080 ffff000008084c4c
== crash(master branch) ===
crash.dave> bt -f 1324
PID: 1324 TASK: ffff80002018be80 CPU: 2 COMMAND: "dhry"
ffff800022f6ae08: ffff00000812ae44 (crash_save_cpu on IRQ stack)
#0 [ffff800022f6ae10] crash_save_cpu at ffff00000812ae44
ffff800022f6ae10: ffff800022f74e00 ffff800020107ed0 -----
ffff800022f6ae20: 0000000000000000 ffff800020107ed0 |local variables
ffff800022f6ae30: ffff000008a26800 0000000000000003 | of callee(*)
ffff800022f6ae40: 0000018800000005 0000000000000001 -----
ffff800022f6ae50: ffff800022f6b010 ffff00000808e718 <= *real* stack frame
#1 [ffff800022f6ae60] handle_IPI at ffff00000808e718 of
crash_save_cpu()
ffff800022f6ae60: ffff000008bce000 0000000000000002 starts here.
ffff800022f6ae70: ffff800022f6ae90 0000000000000000
ffff800022f6ae80: ffff800000000000 0000000000000000
ffff800022f6ae90: 0000000000000000 0000000000000000
ffff800022f6aea0: 0000000000000000 000000000000052c
ffff800022f6aeb0: 0000000000000000 0000000000000000
...
ffff800022f6afa0: ffff800022f6afc0 0000000000000000
ffff800022f6afb0: ffff800022f6afe0 ffff000008675850
ffff800022f6afc0: 0000000000402138 0000000000000000
ffff800022f6afd0: 0000000000000000 0000000000000000
ffff800022f6afe0: ffff800022f6aff0 ffff00000808a820
ffff800022f6aff0: ffff800022f6b010 ffff00000808e758
ffff800022f6b000: ffff000008bce000 0000000000000000
ffff800022f6b010: ffff800022f6b040 ffff0000080815f8
#2 [ffff800022f6b020] gic_handle_irq at ffff0000080815f8
ffff800022f6b020: 0000000000000003 0000000000001fff
ffff800022f6b030: ffff800020107ed0 ffff000008e60c54
ffff800022f6b040: ffff800022f6b080 ffff000008084c4c
=== END ===
(*) append_elf_note()
Thanks,
-Takahiro AKASHI
======8<======
>From b3ca69ace916a5c233ce937954da887ba5487e50 Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
Date: Wed, 8 Jun 2016 11:14:22 +0900
Subject: [PATCH] arm64: dump a stack frame based on fp
Signed-off-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
---
arm64.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arm64.c b/arm64.c
index bdea79c..22f93a2 100644
--- a/arm64.c
+++ b/arm64.c
@@ -1508,12 +1508,12 @@ arm64_print_stackframe_entry(struct bt_info *bt, int
level, struct arm64_stackfr
}
if (bt->flags & BT_FULL) {
- arm64_display_full_frame(bt, frame->sp);
- bt->frameptr = frame->sp;
+ arm64_display_full_frame(bt, frame->fp);
+ bt->frameptr = frame->fp;
}
fprintf(ofp, "%s#%d [%8lx] %s at %lx", level < 10 ? " " :
"", level,
- frame->sp, name_plus_offset ? name_plus_offset : name,
frame->pc);
+ frame->fp, name_plus_offset ? name_plus_offset : name,
frame->pc);
if (BT_REFERENCE_CHECK(bt))
arm64_do_bt_reference_check(bt, frame->pc, name);
@@ -1571,12 +1571,10 @@ arm64_unwind_frame(struct bt_info *bt, struct
arm64_stackframe *frame)
{
unsigned long high, low, fp;
unsigned long stack_mask;
- unsigned long irq_stack_ptr, orig_sp, sp_in;
+ unsigned long irq_stack_ptr, orig_sp;
struct arm64_pt_regs *ptregs;
struct machine_specific *ms;
- sp_in = frame->sp;
-
stack_mask = (unsigned long)(ARM64_STACK_SIZE) - 1;
fp = frame->fp;
@@ -1613,7 +1611,7 @@ arm64_unwind_frame(struct bt_info *bt, struct
arm64_stackframe *frame)
ptregs = (struct arm64_pt_regs
*)&bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(orig_sp))];
frame->sp = orig_sp;
frame->pc = ptregs->pc;
- bt->bptr = sp_in;
+ bt->bptr = fp;
if (CRASHDEBUG(1))
error(INFO,
"arm64_unwind_frame: switch stacks: fp: %lx sp: %lx pc: %lx\n",
@@ -2004,8 +2002,11 @@ arm64_print_exception_frame(struct bt_info *bt, ulong
pt_regs, int mode, FILE *o
ulong LR, SP, offset;
char buf[BUFSIZE];
+#if 0 /* FIXME? */
if (bt->flags & BT_FULL)
arm64_display_full_frame(bt, pt_regs);
+}
+#endif
if (CRASHDEBUG(1))
fprintf(ofp, "pt_regs: %lx\n", pt_regs);
--
2.8.1
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility