[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201012100318.4ikyffo3mcnq6bnl@linutronix.de>
Date: Mon, 12 Oct 2020 12:03:18 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: Xiaoming Ni <nixiaoming@...wei.com>, dima@...sta.com,
will@...nel.org, jpoimboe@...hat.com, akpm@...ux-foundation.org,
christian.brauner@...ntu.com, viro@...iv.linux.org.uk,
ldufour@...ux.ibm.com, amanieu@...il.com, walken@...gle.com,
ben.dooks@...ethink.co.uk, tglx@...utronix.de, mingo@...nel.org,
vincent.whitchurch@...s.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, wangle6@...wei.com,
luohaizheng@...wei.com
Subject: Re: [PATCH] arm:traps: Don't print stack or raw PC/LR values in
backtraces
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)
Sebastian
Powered by blists - more mailing lists