When trying to map a bunch of instruction addresses to their respective
threads, I kept getting a lot of bogus entries [I forget the exact
reason as I patched my code months ago].
Looking through ip__resolve_ams, I noticed the check for
if (al.sym)
and realized, most times I have an al.map definition but sometimes an
al.sym is undefined. In the cases where al.sym is undefined, the loop
keeps going even though a valid al.map exists.
Modify this check to use the more reliable al.map. This fixed my bogus
entries.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1393386227-149412-2-git-send-email-dzickus@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When compiling perf tool code with gcc 4.4.7 I'm getting
following error:
CC util/session.o
cc1: warnings being treated as errors
util/session.c: In function ‘perf_session_deliver_event’:
tools/perf/util/include/linux/bitops.h:109: error: dereferencing pointer ‘p’ does break strict-aliasing rules
tools/perf/util/include/linux/bitops.h:101: error: dereferencing pointer ‘p’ does break strict-aliasing rules
util/session.c:697: note: initialized from here
tools/perf/util/include/linux/bitops.h:101: note: initialized from here
make[1]: *** [util/session.o] Error 1
make: *** [util/session.o] Error 2
The aliased types here are u64 and unsigned long pointers, which is safe
for the find_first_bit processing.
This error shows up for me only for gcc 4.4 on 32bit x86, even for
-Wstrict-aliasing=3, while newer gcc are quiet and scream here for
-Wstrict-aliasing={2,1}. Looks like newer gcc changed the rules for
strict alias warnings.
The gcc documentation offers workaround for valid aliasing by using
__may_alias__ attribute:
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Type-Attributes.html
Using this workaround for the find_first_bit function.
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1393434867-20271-1-git-send-email-jolsa@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Stephane reported that perf report and annotate failed to process data
using lots of (> 500) shared libraries. It was because of the limit on
number of open files (ulimit -n).
Currently when perf loads a DSO, it'll look for normal and dynamic
symbol tables. And if it fails to find out both tables, it'll iterate
all of possible symtab types. But many of them are useless since they
have no additional information and the problem is that it's not closing
those files even though they're not used. Fix it.
Reported-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Cody P Schafer <cody@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1392859976-32760-2-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The TUI of perf report and top support annotation, but stdio and GTK
don't. So it should be checked before calling hist_entry__inc_addr_
samples() to avoid wasting resources that will never be used.
perf annotate need it regardless of UI and sort keys, so the check
of whether to allocate resources should be on the tools that have
annotate as an option in the TUI, 'report' and 'top', not on the
function called by all of them.
It caused perf annotate on ppc64 to produce zero output, since the
buckets were not being allocated.
Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1392859976-32760-1-git-send-email-namhyung@kernel.org
[ Renamed (report,top)__needs_annotate() to ui__has_annotation() ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
"perf list" listing of hardware events doesn't work on older ARM devices.
The change enabling event detection:
commit b41f1cec91
Author: Namhyung Kim <namhyung.kim@lge.com>
Date: Tue Aug 27 11:41:53 2013 +0900
perf list: Skip unsupported events
uses the following code in tools/perf/util/parse-events.c:
struct perf_event_attr attr = {
.type = type,
.config = config,
.disabled = 1,
.exclude_kernel = 1,
};
On ARM machines pre-dating the Cortex-A15 this doesn't work, as these
machines don't support .exclude_kernel. So starting with 3.12 "perf
list" does not report any hardware events at all on older machines (seen
on Rasp-Pi, Pandaboard, Beagleboard, etc).
This version of the patch makes changes suggested by Namhyung Kim to
check for EACCESS and retry (instead of just dropping the
exclude_kernel) so we can properly handle machines where
/proc/sys/kernel/perf_event_paranoid is set to 2.
Reported-by: Chad Paradis <chad.paradis@umit.maine.edu>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Chad Paradis <chad.paradis@umit.maine.edu>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1312301536150.28814@vincent-weaver-1.um.maine.edu
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Fix perf-probe not to add offset value twice to uprobe probe address
when post processing.
The tevs[i].point.address struct member is the address of symbol+offset,
but current perf-probe adjusts the point.address by adding the offset.
As a result, the probe address becomes symbol+offset+offset. This may
cause unexpected code corruption. Urgent fix is needed.
Without this fix:
---
# ./perf probe -x ./perf dso__load_vmlinux+4
# ./perf probe -l
probe_perf:dso__load_vmlinux (on 0x000000000006d2b8)
# nm ./perf.orig | grep dso__load_vmlinux\$
000000000046d0a0 T dso__load_vmlinux
---
You can see the given offset is 3 but the actual probed address is
dso__load_vmlinux+8.
With this fix:
---
# ./perf probe -x ./perf dso__load_vmlinux+4
# ./perf probe -l
probe_perf:dso__load_vmlinux (on 0x000000000006d2b4)
---
Now the problem is fixed.
Note: This bug is introduced by
commit fb7345bbf7
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: "David A. Long" <dave.long@linaro.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: yrl.pp-manager.tt@hitachi.com
Link: http://lkml.kernel.org/r/20140205051858.6519.27314.stgit@kbuild-fedora.yrl.intra.hitachi.co.jp
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Commit 71ae8aac ("lib: introduce arch optimized hash library") added an
include to <linux/hash.h> for setting up an architecture specific fast
hash.
Since perf includes directly the non-uapi kernel header, it cannot find
<asm/hash.h> on non-x86 and thus prevents perf to be compiled on every
architecture other than x86.
The problem is the inclusion of <asm/hash.h> in hash.h that results in
the following error originating from util/evlist.c:
fatal error: asm/hash.h: No such file or directory
This commit simply adds an empty <asm/hash.h> stub/file to fix the
compile issue on non-x86 architectures.
As perf does not use any of these new functions, it fixes the
compilation and therefore seems to be the most appropriate solution to
go with.
Signed-off-by: Francesco Fusco <ffusco@redhat.com>
Link: http://lkml.kernel.org/r/2cf8143aad65a6aa6fe30325ef8a65847141afa2.1390829373.git.ffusco@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
