From: Masami Hiramatsu <mhiramat@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: mhiramat@kernel.org,
Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 1/2] perf-probe: Ensure debuginfo's build-id is correct
Date: Fri, 12 Jan 2018 01:21:19 +0900 [thread overview]
Message-ID: <20180112012119.224a695b87e106e7bd205da1@kernel.org> (raw)
In-Reply-To: <20180111150631.GC3025@kernel.org>
On Thu, 11 Jan 2018 12:06:31 -0300
Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Em Thu, Jan 11, 2018 at 11:59:32AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Jan 11, 2018 at 09:31:19PM +0900, Masami Hiramatsu escreveu:
> > > On Thu, 4 Jan 2018 13:17:28 -0300
> > > Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > > > Em Mon, Dec 18, 2017 at 04:29:03PM +0900, Masami Hiramatsu escreveu:
> > > > > Ensure that the build-id of debuginfo is correctly matched to
> > > > > target build-id, if not, it warns user to check the system
> > > > > debuginfo package is correctly installed.
>
> > > > So we look at a variety of files looking for one that has a matching
> > > > build-id, I think the warning message should state that the file with
> > > > the unmatched build-id is simply being skipped, no?
>
> > > Actually, this patch series came from your request that you faced
> > > buildid mismatch between running binary and debuginfo binary, and
> > > you asked me to show the message to tell user what he needs to
> > > check.
>
> > > > And why do this at 'perf probe -l' time? I.e. at that point whatever
> > > > probes that are in place already have all the needed debug info?
>
> > > As I pointed, this is not only for perf-probe -l but also perf-probe -a
> >
> > yeah, I recently noticed this while doind a gdb session, where it warned
> > about buildid mismatches.
>
> > I'll apply your patch, thanks for working on it!
>
> Trying to test it, got no warning for the vmlinux case, need to
> investigate, but have not time right now, so, just for documenting it
> here and letting you know:
Thank you for reporting! hmm, I just tested glibc. So I need to
recheck with vmlinux case. Tomorrow I'll investigate it.
Thanks!
>
> [root@jouet ~]# perf probe $verbose "vfs_getname=getname_flags:72 pathname=result->name:string"
> Added new event:
> probe:vfs_getname (on getname_flags:72 with pathname=result->name:string)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe:vfs_getname -aR sleep 1
>
> [root@jouet ~]# perf probe -l
> probe:vfs_getname (on getname_flags:72@acme/git/linux/fs/namei.c with pathname)
> [root@jouet ~]#
> [root@jouet ~]# uname -a
> Linux jouet 4.15.0-rc7+ #6 SMP Thu Jan 11 11:39:11 -03 2018 x86_64 x86_64 x86_64 GNU/Linux
> [root@jouet ~]# mv /lib/modules/4.15.0-rc7+/build/vmlinux /lib/modules/4.15.0-rc7+/build/vmlinux.OFF
> [root@jouet ~]# cp /lib/modules/4.14.0+/build/vmlinux /lib/modules/4.15.0-rc7+/build/vmlinux
> [root@jouet ~]# perf probe -l
> probe:vfs_getname (on getname_flags+147 with pathname)
> [root@jouet ~]# perf probe -v -l
> Opening /sys/kernel/debug/tracing//kprobe_events write=0
> Opening /sys/kernel/debug/tracing//uprobe_events write=0
> Parsing probe_events: p:probe/vfs_getname _text+2601267 pathname=+0(+0(%bx)):string
> Group:probe Event:vfs_getname probe:p
> Looking at the vmlinux_path (8 entries long)
> symsrc__init: build id mismatch for /lib/modules/4.15.0-rc7+/build/vmlinux.
> symsrc__init: cannot get elf header.
> Using /proc/kcore for kernel object code
> Using /proc/kallsyms for symbols
> try to find information at 27b133 in kernel
> Looking at the vmlinux_path (8 entries long)
> symsrc__init: build id mismatch for /lib/modules/4.15.0-rc7+/build/vmlinux.
> Failed to find the path for kernel: No such file or directory
> Failed to find corresponding probes from debuginfo.
> probe:vfs_getname (on getname_flags+147 with pathname)
> [root@jouet ~]#
>
> - Arnaldo
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2018-01-11 16:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 7:28 [PATCH 0/2] perf-probe: Improve warning message for buildid mismatch Masami Hiramatsu
2017-12-18 7:29 ` [PATCH 1/2] perf-probe: Ensure debuginfo's build-id is correct Masami Hiramatsu
2018-01-04 16:17 ` Arnaldo Carvalho de Melo
2018-01-06 14:11 ` Masami Hiramatsu
2018-01-11 12:31 ` Masami Hiramatsu
2018-01-11 14:59 ` Arnaldo Carvalho de Melo
2018-01-11 15:06 ` Arnaldo Carvalho de Melo
2018-01-11 16:21 ` Masami Hiramatsu [this message]
2017-12-18 7:29 ` [PATCH 2/2] perf-probe: Skip searching debuginfo if we know no debuginfo Masami Hiramatsu
2017-12-29 2:52 ` [PATCH 0/2] perf-probe: Improve warning message for buildid mismatch Masami Hiramatsu
2018-01-03 6:51 ` Ravi Bangoria
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=20180112012119.224a695b87e106e7bd205da1@kernel.org \
--to=mhiramat@kernel.org \
--cc=acme@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=ravi.bangoria@linux.vnet.ibm.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
Powered by JetHome