[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzbQBPOwah9gQPHR9WL+zZBOXnHsP6GKmC=QE7qOn+psw@mail.gmail.com>
Date: Mon, 13 Nov 2017 11:14:42 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Fengguang Wu <fengguang.wu@...el.com>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
Network Development <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
intel-wired-lan@...ts.osuosl.org, Michal Marek <mmarek@...e.cz>,
Sam Ravnborg <sam@...nborg.org>,
Dirk Gouders <dirk@...ders.net>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
kbuild test robot <lkp@...el.com>,
"Zhang, Rui" <rui.zhang@...el.com>,
"Lu, Aaron" <aaron.lu@...el.com>
Subject: Re: CONFIG_DEBUG_INFO_SPLIT impacts on faddr2line
On Mon, Nov 13, 2017 at 10:52 AM, Andi Kleen <ak@...ux.intel.com> wrote:
>
> It works for me.
No it clearly does not.
> % ./linux/scripts/faddr2line obj/vmlinux schedule+10
> schedule+10/0x80:
> schedule at arch/x86/include/asm/current.h:15
That's obviously garbage and the problem.
Just look at it. It claims it is in "schedule()", at line 15 in the
file arch/x86/include/asm/current.h.
It's bullshit, and it's almost entirely useless, because while you see
which line it was, you have no idea how it got there, which can be a
big problem particularly with the trivial inlines. _Which_ of the
different invocations of some atomic update was it?
The _real_ output is supposed to be like this:
[torvalds@i7 linux]$ ./scripts/faddr2line vmlinux __schedule+0x314
__schedule+0x314/0x840:
rq_sched_info_arrive at kernel/sched/stats.h:12
(inlined by) sched_info_arrive at kernel/sched/stats.h:99
(inlined by) __sched_info_switch at kernel/sched/stats.h:151
(inlined by) sched_info_switch at kernel/sched/stats.h:158
(inlined by) prepare_task_switch at kernel/sched/core.c:2582
(inlined by) context_switch at kernel/sched/core.c:2755
(inlined by) __schedule at kernel/sched/core.c:3366
See how now it knows that __schedule is in kernel/sched/core.c, and
how it has inlined things and just how it ended up in that header file
and which inline function it was.
So your addr2line is equally broken, and doesn't give the right information.
Put another way: the CONFIG_DEBUG_INFO_SPLIT option is useless. Yes,
it saves time and disk space, but does so at the expense of making all
the debug information unavailable to basic tools.
Linus
Powered by blists - more mailing lists