linux-kernel - Re: [GIT PULL 0/2] perf annotate fix and report improvoment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100526193255.GC9874@ghostprotocols.net>
Date:	Wed, 26 May 2010 16:32:55 -0300
From:	Arnaldo Carvalho de Melo <acme@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	mingo@...e.hu, Peter Zijlstra <peterz@...radead.org>,
	Tom Zanussi <tzanussi@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [GIT PULL 0/2] perf annotate fix and report improvoment

Em Wed, May 26, 2010 at 09:07:05PM +0200, Stephane Eranian escreveu:
> Hi,
> 
> +lkml et al.
> 
> On Wed, May 26, 2010 at 8:23 PM, Arnaldo Carvalho de Melo
> <acme@...radead.org> wrote:
> > Em Wed, May 26, 2010 at 06:45:18PM +0200, Stephane Eranian escreveu:
> >> Attached is the trace for
> >> perf annotate -i ~/perf.data noploop
> >>
> >> I get no output at all (TUI is off). Copied over .debug tarball + perf.data.
> >
> > Looks like the bug I'm investigating now:
> >
> > build id event received for [kernel.kallsyms]: 54b1e7cc3cf52e0db255aab44ce7538eb62655b8
> > build id event received for /tmp/noploop: 875ae61623e89f408b425ca0486a9ec99e3ac73e
> > Looking at the vmlinux_path (5 entries long)
> > No build_id in vmlinux, ignoring it
> > No build_id in /boot/vmlinux, ignoring it
> > No build_id in /boot/vmlinux-2.6.34-tip-default+, ignoring it
> > build_id in /lib/modules/2.6.34-tip-default+/build/vmlinux is
> > 3635a0e8dfc9a1afbd5627c2ba789e41d77d3cd1 while expected is
> > 54b1e7cc3cf52e0db255aab44ce7538eb62655b8, ignoring it
> > No build_id in /usr/lib/debug/lib/modules/2.6.34-tip-default+/vmlinux, ignoring it
> >
> > In my case it is not finding the vmlinux because I'm using RHEL6 Beta
> > kernel without the respective kernel-debuginfo{-common} packages so it
> > doesn't find the vmlinux, uses just /proc/kallsyms and that is not
> > enough for annotation.
> >
> > In your case the problem is that we only cache the kallsyms file in the
> > build-id cache ($HOME/.debug) and that is not enough for annotation, so
> > I have to fix two things:
> >
> I can understand the issue with the kernel symbols.

That has to be fixed and I've got some patches already for that, testing
them now.

> But in this example, I only really care about the symbols in the
> noploop program (/tmp/noploop).
> 
> Missing symbol support for the kernel should not cause perf to avoid
> trying to resolve the symbols in other modules such as my user program
> here.

Right, my bad, I thought that the problem was about the kernel symbols.

Then can you try replacing:

perf annotate -i ~/perf.data noploop

with:

perf annotate -i ~/perf.data -d noploop

And see if that helps?

Because, in the debug output you sent me we have:

Thread 11487 noploop
Functions:
Map: 400000-401000 0 /tmp/noploop
dso: noploop (/tmp/noploop, Functions, loaded, 875ae61623e89f408b425ca0486a9ec99e3ac73e)
 508-58f _init
 590-5bb _start
 5bc-5df call_gmon_start
 5e0-64f __do_global_dtors_aux
 650-67f frame_dummy
 680-681 noploop
 6e0-6ea handler
 6f0-6f1 __libc_csu_fini
 700-788 __libc_csu_init
 790-7c7 __do_global_ctors_aux
 7c8-1000 _fini

So yes, there is a symbol called noploop and it is in the binary
noploop, that _has_ a build-id, and that is in the cache, perf managed
to load its symtab and knows where it is mapped, when it created this
symbol it did:

symbol__new: noploop 0x680-0x681
dso__load_sym: adjusting symbol: st_value: 0x400690 sh_addr: 0x400590 sh_offset: 0x590

Now with perf annotate -D you should get a raw dump that will tell you
if it managed to find the hist_entry for this symbol.

And I checked and there are no other "noploop" symbol in any of the
other DSOs involved.

> > 1. tell about these constraints when a symbol cannot be annotated, not
> > just silently fail
> >
> Agreed, print something like <uknown symbol> or <cannot resolve symbol>
> 
> 
> > 2. cache the vmlinux file in the build-id cache instead of the vmlinux,
> > if the vmlinux file was found, if not, fallback to caching the kallsyms
> > file.
> >
> Don't you need to match buildid here too, the vmlinux linux on the host
> may not match the one on the target, i.e., monitored system.

Right, it is checked if the build-id is in the perf.data file.
 
> > Both can't be cached at the same time as they will have the same
> > build-id and thus at least the symlink would be to one of them.
> >
> > I'll make this even configurable in ~/.perfconfig, on a new [symbol]
> > section, something like:
> >
> > [symbol]
> >
> >        cache_vmlinux = on/off
> >
> > So that people that have issues with the size of these beasts can trade
> > off disk space used by the cache versus being able to do annotation.
> >
> Yes, disk space is an issue.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/