The --full-paths option did not show the full source file paths in the 'perf
annotate' tool, because the value of the option was not propagated into the
related functions.
With this patch the value of the --full-paths option is known to the function
that composes the srcline string, so it prints the full path when necessary.
Committer Note:
This affects annotate when the --print-line option is used:
# perf annotate -h 2>&1 | grep print-line
-l, --print-line print matching source lines (may be slow)
Looking just at the lines that should be affected by this change:
Before:
# perf annotate --print-line --full-paths --stdio fput | grep '\.[ch]:[0-9]\+'
94.44 atomic64_64.h:114
5.56 file_table.c:265
file_table.c:265 5.56 : ffffffff81219a00: callq ffffffff81769360 <__fentry__>
atomic64_64.h:114 94.44 : ffffffff81219a05: lock decq 0x38(%rdi)
After:
# perf annotate --print-line --full-paths --stdio fput | grep '\.[ch]:[0-9]\+'
94.44 /home/git/linux/arch/x86/include/asm/atomic64_64.h:114
5.56 /home/git/linux/fs/file_table.c:265
/home/git/linux/fs/file_table.c:265 5.56 : ffffffff81219a00: callq ffffffff81769360 <__fentry__>
/home/git/linux/arch/x86/include/asm/atomic64_64.h:114 94.44 : ffffffff81219a05: lock decq 0x38(%rdi)
#
Signed-off-by: Michael Petlan <mpetlan@redhat.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: http://permalink.gmane.org/gmane.linux.kernel.perf.user/2365
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When the browser fails to annotate it is difficult for users to find out
what went wrong.
Add some errors for objdump failures that are displayed in the UI.
Note it would be even better to handle these errors smarter, like
falling back to the binary when the debug info is somehow corrupted. But
for now just giving a better error is an improvement.
Committer note:
This works for --stdio, where errors just scroll by the screen:
# perf annotate --stdio intel_idle
Failure running objdump --start-address=0xffffffff81418290 --stop-address=0xffffffff814183ae -l -d --no-show-raw -S -C /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1 2>/dev/null|grep -v /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1|expand
Percent | Source code & Disassembly of vmlinux for cycles:pp
------------------------------------------------------------------
And with that one can use that command line to try to find out more about what
happened instead of getting a blank screen, an improvement.
We need tho to improve this further to get it to work with other UIs, like
--tui and --gtk, where it continues showing a blank screen, no messages, as
the pr_err() used is enough just for --stdio.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1446779167-18949-1-git-send-email-andi@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The "/proc/kcore requires CAP_SYS_RAWIO" message comes up all the time
for 'perf script' if vmlinux is not found and the user isn't root, even
when the kernel is not being traced and even though the message is only
really relevant for annotation.
Change it to pr_debug and instead put a note in the message displayed if
annotation is not possible.
Also, the file being accessed might not be /proc/kcore. Tools can be
directed to a different location using the --kallsyms option in which
case kcore is expected to be in the same directory. Adjust the message
so it is not misleading in that case.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Li Zhang <zhlcindy@linux.vnet.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/1440065260-8802-1-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Fix the following 32-bit compilation errors:
util/annotate.c: In function ‘addr_map_symbol__account_cycles’:
util/annotate.c:643:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘u64’ [-Werror=format=]
pr_debug2("BB with bad start: addr %lx start %lx sym %lx saddr %lx\n",
^
util/annotate.c:643:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘u64’ [-Werror=format=]
util/annotate.c:643:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘u64’ [-Werror=format=]
These were introduced by the patch:
"perf report: Add infrastructure for a cycles histogram"
Also change the 'saddr' variable from 'unsigned long' to 'u64'
noting that theoretically we could be processing data captured
on a 64-bit machine but processing it on a 32-bit machine.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Fixes: d4957633bf ("perf report: Add infrastructure for a cycles histogram")
Link: http://lkml.kernel.org/r/1439536294-18241-1-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This adds the basic infrastructure to keep track of cycle counts per
basic block for annotate. We allocate an array similar to the normal
accounting, and then account branch cycles there.
We handle two cases:
cycles per basic block with start and cycles per branch (these are later
used for either IPC or just cycles per BB)
In the start case we cannot handle overlaps, so always the longest basic
block wins.
For the cycles per branch case everything is accurately accounted.
v2: Remove unnecessary checks. Slight restructure. Move
symbol__get_annotation to another patch. Move histogram allocation.
v3: Merged with current tree
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1437233094-12844-4-git-send-email-andi@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When annotating source/disasm lines the perf tools parse the output of
objdump, trying to provide augmented output that allows navigating
jumps, calls, etc.
But when a line output by objdump can't be parsed the annotation code
falls back to just presenting the unparsed line.
When fixing a leak in the 0fb9f2aab7 commit ("perf annotate: Fix
memory leaks in LOCK handling") we failed to take that into account and
instead tried to free one of the data structures that should be freed
only when successfully allocated, oops, segfault.
There was a change in the way the objdump output for lock prefixed
instructions is formatted that lead the relevant parser to fail to grok
it.
At least RHEL7 works ok, but Fedora 20 segfaults.
Fix it by making the ins__delete() destructor work like the most basic
destructor: free().
Namely make it accept a NULL pointer and when handling it just do
nothing.
Further investigation is needed to figure out the nature of the objdump
output change so as to make the parser grok it.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rabin Vincent <rabin@rab.in>
Link: http://lkml.kernel.org/n/tip-7wsy0zo292pif0yjoqpfryrz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
With srcline key/sort'ing it's useful to have line numbers in the
annotate window. This patch implements this.
Use objdump -l to request the line numbers and save them in the line
structure. Then the browser displays them for source lines.
The line numbers are not displayed by default, but can be toggled on
with 'k'
There is one unfortunate problem with this setup. For lines not
containing source and which are outside functions objdump -l reports
line numbers off by a few: it always reports the first line number in
the next function even for lines that are outside the function.
I haven't found a nice way to detect/correct this. Probably objdump has
to be fixed.
See https://sourceware.org/bugzilla/show_bug.cgi?id=16433
The line numbers are still useful even with these problems, as most are
correct and the ones which are not are nearby.
v2: Fix help text. Handle (discriminator...) output in objdump.
Left align the line numbers.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1415844328-4884-9-git-send-email-andi@firstfloor.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>
Michael Petlan
Andi Kleen
Arnaldo Carvalho de Melo
Adrian Hunter
Martin Liška
Ingo Molnar
Jiri Olsa
Rabin Vincent
Alex Converse
Arnaldo Carvalho de Melo
Namhyung Kim