Messages in this thread | | | Date | Mon, 12 Oct 2020 12:06:44 +0100 | From | Russell King - ARM Linux admin <> | Subject | Re: [PATCH] arm:traps: Don't print stack or raw PC/LR values in backtraces |
| |
On Mon, Oct 12, 2020 at 12:03:18PM +0200, Sebastian Andrzej Siewior wrote: > On 2020-10-11 22:32:38 [+0100], Russell King - ARM Linux admin wrote: > > I don't have a problem getting rid of the hex numbers in [< >] > > although then I will need to convert the symbol back to an address > > using the vmlinux to then calculate its address to then find the > > appropriate place in the objdump output - because objdump does > > _not_ use the symbol+offset annotation. Yes, I really do look up > > the numeric addresses in the objdump output to then read the > > disassembly. > > > > $ objdump -d vmlinux | less > > > > and then search for the address is the fastest and most convenient > > way for me rather than having to deal with some random script. > > > > Maybe I'm just antequated about how I do my debugging, but this > > seems to me to be the most efficient and fastest way. > > besides what Josh mentioned, there is also > scripts/decode_stacktrace.sh path-vmlinux > > where you can copy/paste your complete stack trace / dmesg and it will > decode it line by line. So if you invoke > scripts/decode_stacktrace.sh vmlinux.o > > and paste this: > > |[ 7.568155] 001: PC is at do_work_pending+0x190/0x5c4 > |[ 7.568641] 001: LR is at slow_work_pending+0xc/0x20 > |[ 7.569232] 001: Backtrace: > |[ 7.569367] 001: [<c020c2d0>] (do_work_pending) from [<c02000cc>] (slow_work_pending+0xc/0x20) > > you get this in return: > |[ 7.568155] 001: PC is at do_work_pending (arch/arm/kernel/signal.c:616 arch/arm/kernel/signal.c:670) > |[ 7.568641] 001: LR is at slow_work_pending (arch/arm/kernel/entry-common.S:112) > |[ 7.569232] 001: Backtrace: > |[ 7.569367] 001: (do_work_pending) from slow_work_pending (arch/arm/kernel/entry-common.S:112)
That's assuming:
1) you have built the kernel with debug information enabled (I never do, it uses way too much disk space) 2) you want to look at the C code rather than the assembly.
I think you've assumed that I debug oopses by looking primerily at C code. I don't. I understand the assembly and then look at the C code.
I've stated in the past in detail how I debug the kernel when someone has posted a hard-to-debug oops, going through the validation of the dumped state, sometimes to find the bug in a function several parents up from the one where the oops actually occurred.
However, as I've said, I have little problem removing the hex values inside [< >] as I can work around that. Removing the other information is what I'm objecting to.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
| |