On Tue, Nov 06, 2018 at 08:39:01AM +0000, Mark Rutland wrote: > On Tue, Nov 06, 2018 at 03:19:35PM +0800, Zhaoyang Huang wrote: > > From: Zhaoyang Huang <[email protected]> > > > > In some cases, the instruction of "bl foo1" will be the last one of the > > foo2[1], which will cause the lr be the first instruction of the adjacent > > foo3[2]. Hence, the backtrace will show the weird result as bellow[3]. > > The patch will fix it by miner 4 of the lr when dump_backtrace > > This has come up in the past (and a similar patch has been applied, then > reverted). > > In general, we don't know that a function call was made via BL, and therefore > cannot know that LR - 4 is the address of the caller. The caller could set up > the LR as it likes, then B or BR to the callee, and depending on how the basic > blocks get laid out in memory, LR - 4 might point at something completely > different. > > More ideally, the compiler wouldn't end a function with a BL. When does that > happen, and is there some way we could arrange for that to not happen? e.g. > somehow pad a NOP after the BL.
It's a consequence of having __noreturn isn't it? __noreturn frees the compiler from the burden of having to produce a valid return stack... so it doesn't and unwinding becomes hard. Daniel. > > [1] > > 0xffffff80081e6b04 <handle_mm_fault+3996>: adrp x0, > > 0xffffff8008ca8000 > > 0xffffff80081e6b08 <handle_mm_fault+4000>: add x0, x0, #0x5a8 > > 0xffffff80081e6b0c <handle_mm_fault+4004>: bl 0xffffff80081b0ca0 > > <panic> > > 0xffffff80081e6b10 <access_remote_vm>: stp x29, x30, [sp,#-64]! > > 0xffffff80081e6b14 <access_remote_vm+4>: mov x29, sp > > > > [2] > > crash_arm64> rd ffffffc02eec3bd0 2 > > ffffffc02eec3bd0: ffffffc02eec3cb0 ffffff80081e6b10 > > > > [3] > > wrong: > > [<ffffff80081b0d90>] panic+0xf0/0x24c > > [<ffffff80081e6b10>] access_remote_vm+0x0/0x5c > > [<ffffff800809d7b0>] do_page_fault+0x290/0x3b8 > > [<ffffff8008081570>] do_mem_abort+0x64/0xdc > > > > correct: > > [ffffffc02eec3bd0] panic at ffffff80081b0da4 > > [ffffffc02eec3cb0] handle_mm_fault at ffffff80081e6b0c > > [ffffffc02eec3d80] do_page_fault at ffffff800809d7ac > > [ffffffc02eec3df0] do_mem_abort at ffffff800808156c > > > > Signed-off-by: Zhaoyang Huang <[email protected]> > > --- > > arch/arm64/kernel/traps.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > > index d399d45..7a097cc 100644 > > --- a/arch/arm64/kernel/traps.c > > +++ b/arch/arm64/kernel/traps.c > > @@ -113,7 +113,7 @@ void dump_backtrace(struct pt_regs *regs, struct > > task_struct *tsk) > > > > if (tsk == current) { > > frame.fp = (unsigned long)__builtin_frame_address(0); > > - frame.pc = (unsigned long)dump_backtrace; > > + frame.pc = (unsigned long)dump_backtrace + 4; > > } else { > > /* > > * task blocked in __switch_to > > @@ -130,7 +130,7 @@ void dump_backtrace(struct pt_regs *regs, struct > > task_struct *tsk) > > do { > > /* skip until specified stack frame */ > > if (!skip) { > > - dump_backtrace_entry(frame.pc); > > + dump_backtrace_entry(frame.pc - 4); > > } else if (frame.fp == regs->regs[29]) { > > skip = 0; > > /* > > -- > > 1.9.1 > >
