From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: "Wangnan (F)" <wangnan0@huawei.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: perf test BPF failing on f24: fix
Date: Thu, 4 Aug 2016 09:48:57 -0300 [thread overview]
Message-ID: <20160804124857.GH14639@kernel.org> (raw)
In-Reply-To: <20160804153221.8aa29dfc5533b14089bd7470@kernel.org>
Em Thu, Aug 04, 2016 at 03:32:21PM +0900, Masami Hiramatsu escreveu:
> On Wed, 3 Aug 2016 17:04:15 -0300
> Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > Em Wed, Aug 03, 2016 at 11:45:57PM +0900, Masami Hiramatsu escreveu:
> > > > If we remove vmlinux, perf should use /proc/kallsyms. I think
> > I am not removing vmlinux, it is being used, its just that the function
> > chosen by the 'perf test BPF' testcase isn't there.
> > So lets go again trying to chase this without missing a single step of
> > the way:
> > We start with:
> >
> > [root@jouet ~]# perf test bpf
> > 37: Test BPF filter :
> > 37.1: Test basic BPF filtering : FAILED!
> > 37.2: Test BPF prologue generation : Skip
> > 37.3: Test BPF relocation checker : Skip
> > [root@jouet ~]#
> >
> > Ok, so we add -v to get more information:
> >
> > [root@jouet ~]# perf test -v bpf
> > <BIG SNIP>
> > bpf: config program 'func=sys_epoll_wait'
> > symbol:sys_epoll_wait file:(null) line:0 offset:0 return:0 lazy:(null)
> > bpf: config 'func=sys_epoll_wait' is ok
> > Looking at the vmlinux_path (8 entries long)
> > Using /lib/modules/4.7.0+/build/vmlinux for symbols
> > Open Debuginfo file: /lib/modules/4.7.0+/build/vmlinux
> > Try to find probe point from debuginfo.
> > Symbol sys_epoll_wait address found : ffffffffbd295b50
> > Failed to find debug information for address ffffffffbd295b50
> > Probe point 'sys_epoll_wait' not found.
> > bpf_probe: failed to convert perf probe eventsFailed to add events
> > selected by BPF
> > test child finished with -1
> > ---- end ----
> > Test BPF filter subtest 0: FAILED!
> >
> > --------------
> >
> > See? It _is_ using /lib/modules/4.7.0+/build/vmlinux, and it should
> > because:
> >
> > [acme@jouet linux]$ file /lib/modules/4.7.0+/build/vmlinux
> > /lib/modules/4.7.0+/build/vmlinux: ELF 64-bit LSB executable, x86-64,
> > version 1 (SYSV), statically linked,
> > BuildID[sha1]=a08d121dcee2a0ea0cfa5d84363de0c1cfdc729a, not stripped
> > [acme@jouet linux]$
> >
> > Its the kernel that is in use:
> >
> > [acme@jouet linux]$ perf buildid-list --kernel
> > a08d121dcee2a0ea0cfa5d84363de0c1cfdc729a
>
> > [acme@jouet linux]$ perf buildid-list -h --kernel
> >
> > Usage: perf buildid-list [<options>]
> >
> > -k, --kernel Show current kernel build id
> >
> > [acme@jouet linux]$
> >
> > And, in this vmlinux file, there is _no_ such function:
> >
> > [acme@jouet linux]$ readelf -wi /lib/modules/4.7.0+/build/vmlinux | grep -w sys_epoll_wait
> > [acme@jouet linux]$
> >
> > Exactly like the 'perf probe -v bpf' says:
> >
> > Symbol sys_epoll_wait address found : ffffffffbd295b50
> > Failed to find debug information for address ffffffffbd295b50
> >
> > -----
> >
> > It mapped it to an address, sure, it found it in /proc/kallsyms, but
> > then it didn't find it in the matching vmlinux file.
> >
> > Since the test was working before, when did it stop to be available on
> > vmlinux?
>
> Would you remember the previous test was done with this kernel or other one?
>
> Actually, I could put probes on sys_epoll_wait on F24 standard kernel.
No, you did not, you put probes in SyS_epoll_wait, because the part that
is failing for me, i.e. mapping sys_epoll_wait kallsyms's addr to
SyS_epoll_wait's addr is working for you.
I will test with the standard kernel for f24, this is my hunch as well,
that something on the 4.7.0 kernel series (or one after the
f24/ubuntu-you-use ones) is causing this, will diff the configs
more below
> -----
> [mhiramat@devbox perf]$ sudo ./perf probe -vnf sys_epoll_wait
> probe-definition(0): sys_epoll_wait
> symbol:sys_epoll_wait file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Looking at the vmlinux_path (8 entries long)
> Using /usr/lib/debug/lib/modules/4.6.4-301.fc24.x86_64/vmlinux for symbols
> Open Debuginfo file: /usr/lib/debug/lib/modules/4.6.4-301.fc24.x86_64/vmlinux
> Try to find probe point from debuginfo.
> Symbol sys_epoll_wait address found : ffffffff81292d60
> Matched function: SyS_epoll_wait
> found inline addr: 0xffffffff812930f3
> Probe point found: compat_SyS_epoll_pwait+147
> found inline addr: 0xffffffff81292ed6
> Probe point found: SyS_epoll_pwait+134
> found inline addr: 0xffffffff81292d60
> Probe point found: SyS_epoll_wait+0
> Found 3 probe_trace_events.
> Opening /sys/kernel/debug/tracing//kprobe_events write=1
> Writing event: p:probe/sys_epoll_wait _text+2699507
> Writing event: p:probe/sys_epoll_wait_1 _text+2698966
> Writing event: p:probe/sys_epoll_wait_2 _text+2698592
> Added new events:
> probe:sys_epoll_wait (on sys_epoll_wait)
> probe:sys_epoll_wait_1 (on sys_epoll_wait)
> probe:sys_epoll_wait_2 (on sys_epoll_wait)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe:sys_epoll_wait_2 -aR sleep 1
>
> -----
> FYI, if perf-probe failed to find the symbol in debuginfo, it tries to find its address
> from symbol table(kallsyms, here), and then tries to convert the address to the symbol
> in debuginfo again. It seems that in your case this convert process is failed.
Yeah, that is what is failing for me.
> Then, could you grep DEBUG_INFO in .config? I guess your kernel enables some
> reduced debuginfo related config enabled...
If that is the case, then we better add a proper warning because this is
very subtle :-)
Checking...
[acme@jouet linux]$ grep ^CONFIG_DEBUG_ ../build/v4.7.0+/.config | grep 'INFO\|REDUCED'
CONFIG_DEBUG_INFO=y
[acme@jouet linux]$
Nope.
- Arnaldo
next prev parent reply other threads:[~2016-08-04 12:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 19:51 perf test BPF failing on f24: fix Arnaldo Carvalho de Melo
2016-08-02 21:03 ` Alexei Starovoitov
2016-08-03 2:15 ` Arnaldo Carvalho de Melo
2016-08-03 2:57 ` Alexei Starovoitov
2016-08-03 2:41 ` Wangnan (F)
2016-08-03 3:41 ` Wangnan (F)
2016-08-03 8:19 ` Wangnan (F)
2016-08-03 14:45 ` Masami Hiramatsu
2016-08-03 20:04 ` Arnaldo Carvalho de Melo
2016-08-04 6:32 ` Masami Hiramatsu
2016-08-04 12:48 ` Arnaldo Carvalho de Melo [this message]
2016-08-04 19:36 ` Arnaldo Carvalho de Melo
2016-08-04 21:47 ` Arnaldo Carvalho de Melo
2016-08-05 9:45 ` Masami Hiramatsu
2016-08-05 14:35 ` Arnaldo Carvalho de Melo
2016-08-05 15:55 ` Arnaldo Carvalho de Melo
2016-08-06 10:29 ` Masami Hiramatsu
2016-08-08 19:33 ` Arnaldo Carvalho de Melo
2016-08-09 19:17 ` [tip:perf/urgent] perf probe: Adjust map->reloc offset when finding kernel symbol from map tip-bot for Masami Hiramatsu
2016-08-03 23:08 ` perf test BPF failing on f24: fix Masami Hiramatsu
2016-08-04 1:50 ` Wangnan (F)
2016-08-04 8:47 ` Masami Hiramatsu
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=20160804124857.GH14639@kernel.org \
--to=acme@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=wangnan0@huawei.com \
/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).