user/sven/linux.git/tools/perf/util, branch v3.14.2

perf machine: Use map as success in ip__resolve_ams

2014-03-10T14:19:36Z

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 Cc: Jiri Olsa Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1393386227-149412-2-git-send-email-dzickus@redhat.com Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Fix crash in elf_section_by_name

2014-03-10T14:17:14Z

Fixing crash in elf_section_by_name function caused by missing section name in elf binary. Reported-by: Albert Strasheim Signed-off-by: Jiri Olsa Cc: Albert Strasheim Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1393767127-599-1-git-send-email-jolsa@redhat.com Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix strict alias issue for find_first_bit

2014-02-28T13:39:40Z

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 Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1393434867-20271-1-git-send-email-jolsa@redhat.com Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Destroy unused symsrcs

2014-02-24T14:13:08Z

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 Signed-off-by: Namhyung Kim Cc: Cody P Schafer Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1392859976-32760-2-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf annotate: Check availability of annotate when processing samples

2014-02-24T14:12:55Z

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 Signed-off-by: Namhyung Kim Cc: Anton Blanchard Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra 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

perf list: Fix checking for supported events on older kernels

2014-02-10T14:34:31Z

"perf list" listing of hardware events doesn't work on older ARM devices. The change enabling event detection: commit b41f1cec91c37eeea6fdb15effbfa24ea0a5536b Author: Namhyung Kim 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 Signed-off-by: Vince Weaver Acked-by: Namhyung Kim Cc: Chad Paradis Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra 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

perf tools: Handle PERF_RECORD_HEADER_EVENT_TYPE properly

2014-02-10T14:34:31Z

We removed event types from data file in following commits: 6065210 perf tools: Remove event types framework completely 44b3c57 perf tools: Remove event types from perf data file We no longer need this information, because we can get it directly from tracepoints. But we still need to handle PERF_RECORD_HEADER_EVENT_TYPE event for the sake of old perf data files created in pipe mode like: $ perf.3.4 record -o - foo >perf.data $ perf.312 report -i - < perf.data Reported-by: Stephane Eranian Signed-off-by: Jiri Olsa Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1391524668-12546-1-git-send-email-jolsa@redhat.com Signed-off-by: Arnaldo Carvalho de Melo

perf probe: Do not add offset twice to uprobe address

2014-02-10T14:34:30Z

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 fb7345bbf7fad9bf72ef63a19c707970b9685812 Signed-off-by: Masami Hiramatsu Cc: "David A. Long" Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Oleg Nesterov Cc: Srikar Dronamraju Cc: Steven Rostedt 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

perf tools: Adjust kallsyms for relocated kernel

2014-01-31T20:21:53Z

If the kernel is relocated at boot time, kallsyms will not match data recorded previously. That does not matter for modules because they are corrected anyway. It also does not matter if vmlinux is being used for symbols. But if perf tools has only kallsyms then the symbols will not match. Fix by applying the delta gained by comparing the old and current addresses of the relocation reference symbol. Signed-off-by: Adrian Hunter Tested-by: Jiri Olsa Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1391004884-10334-9-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Prevent the use of kcore if the kernel has moved

2014-01-31T20:21:51Z

Use of kcore is predicated upon it matching the recorded data. If the kernel has been relocated at boot time (i.e. since the data was recorded) then do not use kcore. Note that it is possible to make a copy of kcore at the time the data is recorded using 'perf buildid-cache'. Then the perf tools will use the copy because it does match the data. Signed-off-by: Adrian Hunter Tested-by: Jiri Olsa Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1391004884-10334-7-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo