On Fri, Sep 5, 2014 at 2:23 AM, Namhyung Kim [off-list ref] wrote:

Hi Stephane,

On Thu, 4 Sep 2014 16:37:51 +0200, Stephane Eranian wrote:

quoted

On Tue, Aug 26, 2014 at 8:38 AM, Namhyung Kim [off-list ref] wrote:

quoted

There's a problem on finding correct kernel symbols when perf report
runs on a different kernel.  Although a part of the problem was solved
by the prior commit 0a7e6d1b6844 ("perf tools: Check recorded kernel
version when finding vmlinux"), there's a remaining problem still.

When perf records samples, it synthesizes the kernel map using
machine__mmap_name() and ref_reloc_sym like "[kernel.kallsyms]_text".
You can easily see it using 'perf report -D' command.

After finishing record, it goes through the recorded events to find
maps/dsos actually used.  And then record build-id info of them.

During this process, it needs to load symbols in a dso and it'd call
dso__load_vmlinux() since the default value of the symbol_conf.try_
vmlinux_path is true.  However it changes dso->long_name to a real
path of the vmlinux file (e.g. /lib/modules/3.16.0-rc2+/build/vmlinux)
if one is running on a custom kernel.

It resulted in that perf report reads the build-id of the vmlinux, but
cannot use it since it only knows about the [kernel.kallsyms] map.  It
then falls back to possible vmlinux paths by using the recorded kernel
version (in case of a recent version) or a running kernel silently
(which might break the result).  I think it's worth going to the
stable tree.

I can think of a couple of ways to fix it.  In this patch, I changed
to use the name of "[kernel.kallsyms]" for the kernel build-id event
instead of not trying vmlinux paths.  This way we can provide maximum
info (like annotation) with minimum change IMHO.

Before:

  $ perf record -a usleep 1

  $ perf buildid-list
  00d5ff078efe1d30b8492854f259215fd877ce30 /lib/modules/3.16.0-rc2+/build/vmlinux
  78186287bba77069a056a5ccbeb14b7fd2ca3a4b /usr/lib64/libc-2.17.so
  4eadca6cb82e0a85edb87c15b5e3980742514501 /usr/lib64/ld-2.17.so
  1e272ca30081e81ef41935a630eb2f4c636798b4 /usr/lib64/dri/swrast_dri.so

  $ perf buildid-list -H
  0000000000000000000000000000000000000000 [kernel.kallsyms]
  78186287bba77069a056a5ccbeb14b7fd2ca3a4b /usr/lib64/libc-2.17.so
  4eadca6cb82e0a85edb87c15b5e3980742514501 /usr/lib64/ld-2.17.so
  1e272ca30081e81ef41935a630eb2f4c636798b4 /usr/lib64/dri/swrast_dri.so
  0000000000000000000000000000000000000000 /tmp/perf-2523.map

There is something I don't understand in your example above.  The -H
option shows only DSO with samples. So why do you get the buildid
without -H and you get no buildid with -H? In other words, I don't
connect the dots between what -H does on the buildid change for the
kernel. Looks like you have the buildid in the perf.data file.

Without -H, it just prints all DSOs found in build-id table (rebuilt
during read perf data file header) and skips processing events.  But
with -H, it'd process the event records and so set kernel map to
'[kernel.kallsyms]' - since the kernel mmap event always has the name -
and mark it as hit.  Thus the actual vmlinux can't be marked and then
cannot be printed.

Still don't follow this. You're saying because as part of processing the events,
you create or replace the mmap record corresponding to the kernel from the
synthesized mmap (actual kernel filename) to the generic kernel.kallsyms, you
lose the buildid. Why not just transfer it? It has to be the one
listed without -H.
This would certainly be much less confusing (to me at least)! Seems to me
you have one piece of information or the other (buildid or filename) but
never both.

Hmm.. now I'm curious that why the -H option is needed at all.. the perf
record already wrote build-ids that are actually hits..

Thanks,
Namhyung