From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Xiaoming Ni <nixiaoming@huawei.com>,
dima@arista.com, will@kernel.org, jpoimboe@redhat.com,
akpm@linux-foundation.org, christian.brauner@ubuntu.com,
viro@zeniv.linux.org.uk, ldufour@linux.ibm.com,
amanieu@gmail.com, walken@google.com, ben.dooks@codethink.co.uk,
tglx@linutronix.de, mingo@kernel.org,
vincent.whitchurch@axis.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, wangle6@huawei.com,
luohaizheng@huawei.com
Subject: Re: [PATCH] arm:traps: Don't print stack or raw PC/LR values in backtraces
Date: Mon, 12 Oct 2020 12:06:44 +0100 [thread overview]
Message-ID: <20201012110643.GO1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20201012100318.4ikyffo3mcnq6bnl@linutronix.de>
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!
next prev parent reply other threads:[~2020-10-12 11:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-09 7:59 [PATCH] arm:traps: Don't print stack or raw PC/LR values in backtraces Xiaoming Ni
2020-10-09 8:08 ` Russell King - ARM Linux admin
2020-10-09 8:18 ` Sebastian Andrzej Siewior
2020-10-09 8:58 ` Xiaoming Ni
2020-10-11 21:32 ` Russell King - ARM Linux admin
2020-10-12 2:23 ` Xiaoming Ni
2020-10-12 10:03 ` Sebastian Andrzej Siewior
2020-10-12 11:06 ` Russell King - ARM Linux admin [this message]
2020-10-10 17:55 ` Josh Poimboeuf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201012110643.GO1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=amanieu@gmail.com \
--cc=ben.dooks@codethink.co.uk \
--cc=bigeasy@linutronix.de \
--cc=christian.brauner@ubuntu.com \
--cc=dima@arista.com \
--cc=jpoimboe@redhat.com \
--cc=ldufour@linux.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luohaizheng@huawei.com \
--cc=mingo@kernel.org \
--cc=nixiaoming@huawei.com \
--cc=tglx@linutronix.de \
--cc=vincent.whitchurch@axis.com \
--cc=viro@zeniv.linux.org.uk \
--cc=walken@google.com \
--cc=wangle6@huawei.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).