Hi folks, Sorry for many emails. I just found out by turning CONFIG_ARM64_PTR_AUTH off in armv8.3 when building linux, I can avoid this problem. (I noticed the instruction ‘pacia’ in the function assembly code) Thank you. Chan Kim From: Chan Kim <ckim@xxxxxxxxxx> Hi, all I just found that when the linux kernel saves the current x29 and x30 at the new stack bottom, (it usually does that when entering a function) The stored x30 value (lr register) has it top 16bits altered to some strange value. So if I fix those top 16bits to 0xffff in the stack, and if I repeat fixing this stored x30 values, I can see more backtrace information. I filed a bug report to bug.linaro.org. This strange thing doesn’t happen with linux version < 5.10 to me so it doesn’t look like qemu bug. Chan Kim From: Chan Kim <ckim@xxxxxxxxxx> Hello, I hope somebody could check this case. It’s easily reproducible for anybody working with qemu and arm64 linux. I returned to this problem and made another observation.(showing the back-trace is really broken). In another incident of breakpoint at function __driver_attach, (right after it stopped at the function) (gdb) bt #0 __driver_attach (dev=dev@entry=0xffff0000401d1810, data="" <mxc_gpio_driver+40>) at drivers/base/dd.c:1046 #1 0xffff8000107684f8 in bus_for_each_dev (bus=0xffff800011cba910 <platform_bus_type>, start=0x0, data="" <mxc_gpio_driver+40>, fn=0xffff80001076b860 <__driver_attach>) at drivers/base/bus.c:307 #2 0xb8cd80001076a594 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) x/5g $sp 0xffff800011dcbcc0: 0xffff800011dcbd20 0xb8cd80001076a594 0xffff800011dcbcd0: 0xffff80001076b860 0xffff800011bbbbb8 0xffff800011dcbce0: 0x0000000000000000 Because it's right after the pc reached the function __driver_attach, the sp is still not updated from previous function (bus_for_each_dev). And the first two values at the $sp are supposed to be the fp and lr of the previous function (see https://stackoverflow.com/questions/66098678/understanding-aarch64-assembly-function-call-how-is-stack-operated arm64 stores previous function's fp and lr at the bottom of new stack frame as it enters a function). The lr (link register, the address to return after this bus_for_each_dev function) is really 0xb8cd80001076a594 which is weird (not a kernel address). The following 3 values are function arguments for bus_for_each_dev and they look correct. From: Chan Kim <ckim@xxxxxxxxxx> Hi, Mulyadi Thank you for replying. I found CONFIG_DEBUG_FRAME_POINTER, CONFIG_DEBUG_INFO are already set by default. And I tried adding CONFIG_DEBUG_KERNEL, CONFIG_KGDB, CONFIG_GDB_SCRIPTS, CONFIG_STACKTRACE all to no avail. Regards, Chan From: Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> On Fri, Apr 22, 2022 at 7:30 PM Chan Kim <ckim@xxxxxxxxxx> wrote:
It has been long time since I compiled linux kernel but I guess, either you need to compile kernel with enabled frame pointer, and/or you need to enable debug symbol embedded into final kernel image. cmiiw
regards, |
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
