From: Masami Hiramatsu <mhiramat@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: David Ahern <dsahern@gmail.com>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: perf probe -L on ubuntu 16.04
Date: Fri, 20 May 2016 12:23:50 +0900 [thread overview]
Message-ID: <20160520122350.74c8f2a4ef467148ef19bd9f@kernel.org> (raw)
In-Reply-To: <20160519120642.GH28790@kernel.org>
On Thu, 19 May 2016 09:06:42 -0300
Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Em Thu, May 19, 2016 at 11:00:39AM +0900, Masami Hiramatsu escreveu:
> > On Mon, 16 May 2016 22:56:36 -0300
> > Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > > Have you ever tried using 'perf probe' on ubuntu?
>
> > > acme@ubuntu:~/git/linux$ sudo apt-cache search linux-image-$(uname -r)
> > > linux-image-4.4.0-21-generic - Linux kernel image for version 4.4.0 on
> > > 64 bit x86 SMP
> > > linux-image-4.4.0-21-generic-dbgsym - Linux kernel debug image for
> > > version 4.4.0 on 64 bit x86 SMP
> > > acme@ubuntu:~/git/linux$
> > > acme@ubuntu:~/git/linux$
> > >
> > > So those are installed, but then I try:
> > >
> > > root@ubuntu:~# perf probe -vvv -L getname_flags
> > > Looking at the vmlinux_path (8 entries long)
> > > Using /usr/lib/debug/boot/vmlinux-4.4.0-21-generic for symbols
> > > Open Debuginfo file: /usr/lib/debug/boot/vmlinux-4.4.0-21-generic
> > > fname: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c, lineno:125
> > > New line range: 125 to 2147483647
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
>
> Ah, why do we repeat the above line that many times? Are we somehow
> reading this compile unit that many times?!?
Yes, because the getname_flags is inlined by compiler, depends on the
parameter, some lines in the function are never compiled at some call
points. In this case, we have to check every call points so that all
the available lines are found.
BTW, "this CU" has no meaning, it should show the diename, or remove
the useless message.
> > > path: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c
> > > Failed to find source file path.
> > > Error: Failed to show lines. Reason: No such file or directory (Code: -2)
> > > root@ubuntu:~#
>
> > > Have to dig deeper to see where the source code is, ideas?
>
> > It shows the "path" is ;
> > > path: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c
>
> > So, would you have the source code under this temporary directory?
> > (yeah, I guess No)
>
> No, and I couldn't find a package that had it
>
> > Anyway, ubuntu has "linux-source" package, or apt source linux-image-`uname -r`
> > will give you the source tree in current dir.
>
> > After you get a proper kernel source code, you can use -s to show source code.
>
> > -s, --source <directory>
> > path to kernel source
>
> > I ensured it is working correctly by below command.
> > $ perf probe -s ./linux-4.4.0 -L getname_flags
>
> Ok, how about telling the user this package is needed, since we can
> figure out the distro and the package name?
Did we do that already?
> Couldn't it figure out where
> the source code is and also not require using '-s'?
No, actually, ubuntu/debian are not providing kernel source tree package
as redhat/fedora do. User can only download source tarball and extract
it under current working directory. There seems no standard directory
where the source code is extracted to. I think it's debian/ubuntu's
packaging policy.
Anyway, even though we can provide how-to guide for them via Documentation.
I think it's better way because we also have to add some entries to
apt.conf for installing kernel debuginfo.
Thank you,
>
> - Arnaldo
--
Masami Hiramatsu <mhiramat@kernel.org>
prev parent reply other threads:[~2016-05-20 3:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-17 1:56 perf probe -L on ubuntu 16.04 Arnaldo Carvalho de Melo
2016-05-19 2:00 ` Masami Hiramatsu
2016-05-19 12:06 ` Arnaldo Carvalho de Melo
2016-05-20 3:23 ` Masami Hiramatsu [this message]
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=20160520122350.74c8f2a4ef467148ef19bd9f@kernel.org \
--to=mhiramat@kernel.org \
--cc=acme@kernel.org \
--cc=dsahern@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@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