Marc reported use of uninitialized memory:
> In commit "403567217d3f perf symbols: Do not read symbols/data from
> device files" a check to uninitialzied memory was added. This leads to
> the following valgrind output:
>
> ==24515== Syscall param stat(file_name) points to uninitialised byte(s)
> ==24515== at 0x75B26D5: _xstat (in /lib/x86_64-linux-gnu/libc-2.22.so)
> ==24515== by 0x4E548D: stat (stat.h:454)
> ==24515== by 0x4E548D: is_regular_file (util.c:687)
> ==24515== by 0x4A5BEE: dso__load (symbol.c:1435)
> ==24515== by 0x4BB1AE: map__load (map.c:289)
> ==24515== by 0x4BB1AE: map__find_symbol (map.c:333)
> ==24515== by 0x4835B3: thread__find_addr_location (event.c:1300)
> ==24515== by 0x4B5342: add_callchain_ip (machine.c:1652)
> ==24515== by 0x4B5342: thread__resolve_callchain_sample (machine.c:1906)
> ==24515== by 0x4B9E7D: thread__resolve_callchain (machine.c:1958)
> ==24515== by 0x441B3E: process_event (builtin-script.c:795)
> ==24515== by 0x441B3E: process_sample_event (builtin-script.c:920)
> ==24515== by 0x4BEE29: perf_evlist__deliver_sample (session.c:1192)
> ==24515== by 0x4BEE29: machines__deliver_event (session.c:1229)
> ==24515== by 0x4BF770: perf_session__deliver_event (session.c:1286)
> ==24515== by 0x4BF770: ordered_events__deliver_event (session.c:114)
> ==24515== by 0x4C1D17: __ordered_events__flush (ordered-events.c:207)
> ==24515== by 0x4C1D17: ordered_events__flush.part.3 (ordered-events.c:274)
> ==24515== by 0x4BF44C: perf_session__process_user_event (session.c:1325)
> ==24515== by 0x4BF44C: perf_session__process_event (session.c:1451)
> ==24515== Address 0x807c6a0 is 0 bytes inside a block of size 4,096 alloc'd
> ==24515== at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==24515== by 0x4A5BCB: dso__load (symbol.c:1421)
> ==24515== by 0x4BB1AE: map__load (map.c:289)
> ==24515== by 0x4BB1AE: map__find_symbol (map.c:333)
> ==24515== by 0x4835B3: thread__find_addr_location (event.c:1300)
> ==24515== by 0x4B5342: add_callchain_ip (machine.c:1652)
> ==24515== by 0x4B5342: thread__resolve_callchain_sample (machine.c:1906)
> ==24515== by 0x4B9E7D: thread__resolve_callchain (machine.c:1958)
> ==24515== by 0x441B3E: process_event (builtin-script.c:795)
> ==24515== by 0x441B3E: process_sample_event (builtin-script.c:920)
> ==24515== by 0x4BEE29: perf_evlist__deliver_sample (session.c:1192)
> ==24515== by 0x4BEE29: machines__deliver_event (session.c:1229)
> ==24515== by 0x4BF770: perf_session__deliver_event (session.c:1286)
> ==24515== by 0x4BF770: ordered_events__deliver_event (session.c:114)
> ==24515== by 0x4C1D17: __ordered_events__flush (ordered-events.c:207)
> ==24515== by 0x4C1D17: ordered_events__flush.part.3 (ordered-events.c:274)
> ==24515== by 0x4BF44C: perf_session__process_user_event (session.c:1325)
> ==24515== by 0x4BF44C: perf_session__process_event (session.c:1451)
> ==24515== by 0x4C0EAC: __perf_session__process_events (session.c:1804)
> ==24515== by 0x4C0EAC: perf_session__process_events (session.c:1858)
The reason was a typo that passed global 'name' variable as the
is_regular_file argument instead dso->long_name.
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 403567217d ("perf symbols: Do not read symbols/data from device files")
Link: http://lkml.kernel.org/r/1466772025-17471-2-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add few more triplets based on Fedora and Ubuntu binutils (cross tools).
Before applying patch on x86:
( Install binutils-powerpc64-linux-gnu.x86_64 )
$ perf report -i perf.data.powerpc --vmlinux vmlinux.powerpc \
--objdump powerpc64-linux-gnu-objdump
After applying patch on x86:
$ perf report -i perf.data.powerpc --vmlinux vmlinux.powerpc
I.e. it will find the right objdump from the environment data recorded
in the perf.data file + these triplets.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Anton Blanchard <anton@ozlabs.org>
Cc: Daniel Axtens <dja@axtens.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Link: http://lkml.kernel.org/r/1466769240-12376-7-git-send-email-ravi.bangoria@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Many sub-commands use perf_config() but everytime perf_config() is
called, perf_config() always read config files. (i.e. user config
'~/.perfconfig' and system config '$(sysconfdir)/perfconfig')
But it is better to use the config set that already contains all config
key-value pairs to avoid this repetitive work reading the config files
in perf_config(). (the config set mean a static variable 'config_set')
In other words, if new perf_config__init() is called, only first time
'config_set' is initialized collecting all configs from the config
files. And then we could use new perf_config() like old perf_config().
When a sub-command finished, free the config set by perf_config__exit()
at run_builtin().
If we do, 'config_set' can be reused wherever perf_config() is called
and a feature of old perf_config() is the same as new perf_config() work
without the repetitive work that read the config files.
In summary, in order to use features about configuration,
we can call the functions at perf.c and other source files as below.
# initialize a config set
perf_config__init()
# configure actual variables from a config set
perf_config()
# eliminate allocated config set
perf_config__exit()
# destroy existing config set and initialize a new config set.
perf_config__refresh()
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1466691272-24117-3-git-send-email-treeze.taeung@gmail.com
[ 'init' counterpart is 'exit', not 'finish' ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Based on patches from Andi Kleen.
When printing PT instruction traces with perf script it is rather useful
to see some indentation for the call tree. This patch adds a new
callindent field to perf script that prints spaces for the function call
stack depth.
We already have code to track the function call stack for PT, that we
can reuse with minor modifications.
The resulting output is not quite as nice as ftrace yet, but a lot
better than what was there before.
Note there are some corner cases when the thread stack gets code
confused and prints incorrect indentation. Even with that it is fairly
useful.
When displaying kernel code traces it is recommended to run as root, as
otherwise perf doesn't understand the kernel addresses properly, and may
not reset the call stack correctly on kernel boundaries.
Example output:
sudo perf-with-kcore record eg2 -a -e intel_pt// -- sleep 1
sudo perf-with-kcore script eg2 --ns -F callindent,time,comm,pid,sym,ip,addr,flags,cpu --itrace=cre | less
...
swapper 0 [000] 5830.389116586: call irq_exit ffffffff8104d620 smp_call_function_single_interrupt+0x30 => ffffffff8107e720 irq_exit
swapper 0 [000] 5830.389116586: call idle_cpu ffffffff8107e769 irq_exit+0x49 => ffffffff810a3970 idle_cpu
swapper 0 [000] 5830.389116586: return idle_cpu ffffffff810a39b7 idle_cpu+0x47 => ffffffff8107e76e irq_exit
swapper 0 [000] 5830.389116586: call tick_nohz_irq_exit ffffffff8107e7bd irq_exit+0x9d => ffffffff810f2fc0 tick_nohz_irq_exit
swapper 0 [000] 5830.389116919: call __tick_nohz_idle_enter ffffffff810f2fe0 tick_nohz_irq_exit+0x20 => ffffffff810f28d0 __tick_nohz_idle_enter
swapper 0 [000] 5830.389116919: call ktime_get ffffffff810f28f1 __tick_nohz_idle_enter+0x21 => ffffffff810e9ec0 ktime_get
swapper 0 [000] 5830.389116919: call read_tsc ffffffff810e9ef6 ktime_get+0x36 => ffffffff81035070 read_tsc
swapper 0 [000] 5830.389116919: return read_tsc ffffffff81035084 read_tsc+0x14 => ffffffff810e9efc ktime_get
swapper 0 [000] 5830.389116919: return ktime_get ffffffff810e9f46 ktime_get+0x86 => ffffffff810f28f6 __tick_nohz_idle_enter
swapper 0 [000] 5830.389116919: call sched_clock_idle_sleep_event ffffffff810f290b __tick_nohz_idle_enter+0x3b => ffffffff810a7380 sched_clock_idle_sleep_event
swapper 0 [000] 5830.389116919: call sched_clock_cpu ffffffff810a738b sched_clock_idle_sleep_event+0xb => ffffffff810a72e0 sched_clock_cpu
swapper 0 [000] 5830.389116919: call sched_clock ffffffff810a734d sched_clock_cpu+0x6d => ffffffff81035750 sched_clock
swapper 0 [000] 5830.389116919: call native_sched_clock ffffffff81035754 sched_clock+0x4 => ffffffff81035640 native_sched_clock
swapper 0 [000] 5830.389116919: return native_sched_clock ffffffff8103568c native_sched_clock+0x4c => ffffffff81035759 sched_clock
swapper 0 [000] 5830.389116919: return sched_clock ffffffff8103575c sched_clock+0xc => ffffffff810a7352 sched_clock_cpu
swapper 0 [000] 5830.389116919: return sched_clock_cpu ffffffff810a7356 sched_clock_cpu+0x76 => ffffffff810a7390 sched_clock_idle_sleep_event
swapper 0 [000] 5830.389116919: return sched_clock_idle_sleep_event ffffffff810a7391 sched_clock_idle_sleep_event+0x11 => ffffffff810f2910 __tick_nohz_idle_enter
...
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Andi Kleen <ak@linux.intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1466689258-28493-4-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In preparation for using the thread stack to print an indent
representing the stack depth in perf script, add an option to tell
decoders to feed branches to the thread stack. Add support for that
option to Intel PT and Intel BTS.
The advantage of using the decoder to feed the thread stack is that it
happens before branch filtering and so can be used with different itrace
options (e.g. it still works when only showing calls, even though the
thread stack needs to see calls and returns). Also it does not conflict
with using the thread stack to get callchains.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1466689258-28493-3-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The flags field is synthesized and may have a value when Instruction
Trace decoding. The flags are "bcrosyiABEx" which stand for branch,
call, return, conditional, system, asynchronous, interrupt, transaction
abort, trace begin, trace end, and in transaction, respectively.
Change the display so that known combinations of flags are printed more
nicely e.g.: "call" for "bc", "return" for "br", "jcc" for "bo", "jmp"
for "b", "int" for "bci", "iret" for "bri", "syscall" for "bcs",
"sysret" for "brs", "async" for "by", "hw int" for "bcyi", "tx abrt" for
"bA", "tr strt" for "bB", "tr end" for "bE".
However the "x" flag will be displayed separately in those cases e.g.
"jcc (x)" for a condition branch within a transaction.
Example:
perf record -e intel_pt//u ls
perf script --ns -F comm,cpu,pid,tid,time,ip,addr,sym,dso,symoff,flags
...
ls 3689/3689 [001] 2062.020965237: jcc 7f06a958847a _dl_sysdep_start+0xfa (/lib/x86_64-linux-gnu/ld-2.19.so) => 7f06a9588450 _dl_sysdep_start+0xd0 (/lib/x86_64-linux-gnu/ld-2.19.so)
ls 3689/3689 [001] 2062.020965237: jmp 7f06a9588461 _dl_sysdep_start+0xe1 (/lib/x86_64-linux-gnu/ld-2.19.so) => 7f06a95885a0 _dl_sysdep_start+0x220 (/lib/x86_64-linux-gnu/ld-2.19.so)
ls 3689/3689 [001] 2062.020965237: jmp 7f06a95885a4 _dl_sysdep_start+0x224 (/lib/x86_64-linux-gnu/ld-2.19.so) => 7f06a9588470 _dl_sysdep_start+0xf0 (/lib/x86_64-linux-gnu/ld-2.19.so)
ls 3689/3689 [001] 2062.020965904: call 7f06a95884c3 _dl_sysdep_start+0x143 (/lib/x86_64-linux-gnu/ld-2.19.so) => 7f06a9589140 brk+0x0 (/lib/x86_64-linux-gnu/ld-2.19.so)
ls 3689/3689 [001] 2062.020965904: syscall 7f06a958914a brk+0xa (/lib/x86_64-linux-gnu/ld-2.19.so) => 0 [unknown] ([unknown])
ls 3689/3689 [001] 2062.020966237: tr strt 0 [unknown] ([unknown]) => 7f06a958914c brk+0xc (/lib/x86_64-linux-gnu/ld-2.19.so)
ls 3689/3689 [001] 2062.020966237: return 7f06a9589165 brk+0x25 (/lib/x86_64-linux-gnu/ld-2.19.so) => 7f06a95884c8 _dl_sysdep_start+0x148 (/lib/x86_64-linux-gnu/ld-2.19.so)
ls 3689/3689 [001] 2062.020966237: jcc 7f06a95884d7 _dl_sysdep_start+0x157 (/lib/x86_64-linux-gnu/ld-2.19.so) => 7f06a95885f0 _dl_sysdep_start+0x270 (/lib/x86_64-linux-gnu/ld-2.19.so)
ls 3689/3689 [001] 2062.020966237: call 7f06a95885f0 _dl_sysdep_start+0x270 (/lib/x86_64-linux-gnu/ld-2.19.so) => 7f06a958ac50 strlen+0x0 (/lib/x86_64-linux-gnu/ld-2.19.so)
ls 3689/3689 [001] 2062.020966237: jcc 7f06a958ac6e strlen+0x1e (/lib/x86_64-linux-gnu/ld-2.19.so) => 7f06a958ac60 strlen+0x10 (/lib/x86_64-linux-gnu/ld-2.19.so)
...
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Andi Kleen <ak@linux.intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1466689258-28493-2-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There's a problem in machine__findnew_vdso(), vdso buildid generated by a
32-bit machine stores it with the name 'vdso', but when processing buildid on a
64-bit machine with the same 'perf.data', perf will search for vdso named as
'vdso32' and get failed.
This patch tries to find the existing dsos in machine->dsos by thread dso_type.
64-bit thread tries to find vdso with name 'vdso', because all 64-bit vdso is
named as that. 32-bit thread first tries to find vdso with name 'vdso32' if
this thread was run on 64-bit machine, if failed, then it tries 'vdso' which
indicates that the thread was run on 32-bit machine when recording.
Committer note:
Additional explanation by Adrian Hunter:
We match maps to builds ids using the file name - consider
machine__findnew_[v]dso() called in map__new(). So in the context of a perf
data file, we consider the file name to be unique.
A vdso map does not have a file name - all we know is that it is vdso. We look
at the thread to tell if it is 32-bit, 64-bit or x32. Then we need to get the
build id which has been recorded using short name "[vdso]" or "[vdso32]" or
"[vdsox32]".
The problem is that on a 32-bit machine, we use the name "[vdso]". If you take
a 32-bit perf data file to a 64-bit machine, it gets hard to figure out if
"[vdso]" is 32-bit or 64-bit.
This patch solves that problem.
----
This also merges a followup patch fixing a problem introduced by the
original submission of this patch, that would crash 'perf record' when
recording samples for a 32-bit app on a 64-bit system.
Signed-off-by: He Kuang <hekuang@huawei.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1463475894-163531-1-git-send-email-hekuang@huawei.com
Link: http://lkml.kernel.org/r/1466578626-92406-6-git-send-email-hekuang@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The pid sort entry currently aligns pids with 5 digits, which is not
enough for current 4 million pids limit.
This leads to unaligned ':' header-data output when we display 7 digits
pid:
# Children Self Symbol Pid:Command
# ........ ........ ...................... .....................
#
0.12% 0.12% [.] 0x0000000000147e0f 2052894:krava
...
Adding 2 more digit to properly align the pid limit:
# Children Self Symbol Pid:Command
# ........ ........ ...................... .......................
#
0.12% 0.12% [.] 0x0000000000147e0f 2052894:krava
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1466459899-1166-9-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add stackcollapse.py script as an example of parsing call chains, and
also of using optparse to access command line options.
The flame graph tools include a set of scripts that parse output from
various tools (including "perf script"), remove the offsets in the
function and collapse each stack to a single line. The website also
says "perf report could have a report style [...] that output folded
stacks directly, obviating the need for stackcollapse-perf.pl", so here
it is.
This script is a Python rewrite of stackcollapse-perf.pl, using the perf
scripting interface to access the perf data directly from Python.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Brendan Gregg <bgregg@netflix.com>
Link: http://lkml.kernel.org/r/1460467573-22989-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add a 'llvm.dump-obj' config option to enable perf dump BPF object files
compiled by LLVM.
This option is useful when using BPF objects in embedded platforms.
LLVM compiler won't be deployed in these platforms, and currently we
don't support dynamic compiling library.
Before this patch users have to explicitly issue llvm commands to
compile BPF scripts, and can't use helpers (like include path detection
and default macros) in perf. With this option, user is allowed to use
perf to compile their BPF objects then copy them into their embedded
platforms.
Committer notice:
Testing it:
# cat ~/.perfconfig
[llvm]
dump-obj = true
#
# ls -la filter.o
ls: cannot access filter.o: No such file or directory
# cat filter.c
#include <uapi/linux/bpf.h>
#define SEC(NAME) __attribute__((section(NAME), used))
SEC("func=hrtimer_nanosleep rqtp->tv_nsec")
int func(void *ctx, int err, long nsec)
{
return nsec > 1000;
}
char _license[] SEC("license") = "GPL";
int _version SEC("version") = LINUX_VERSION_CODE;
# trace -e nanosleep --event filter.c usleep 6
LLVM: dumping filter.o
0.007 ( 0.007 ms): usleep/13976 nanosleep(rqtp: 0x7ffc5847f640 ) ...
0.007 ( ): perf_bpf_probe:func:(ffffffff811137d0) tv_nsec=6000)
0.070 ( 0.070 ms): usleep/13976 ... [continued]: nanosleep()) = 0
# ls -la filter.o
-rw-r--r--. 1 root root 776 Jun 20 17:01 filter.o
# readelf -SW filter.o
There are 7 section headers, starting at offset 0x148:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .strtab STRTAB 0000000000000000 0000e8 00005a 00 0 0 1
[ 2] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4
[ 3] func=hrtimer_nanosleep rqtp->tv_nsec PROGBITS 0000000000000000 000040 000028 00 AX 0 0 8
[ 4] license PROGBITS 0000000000000000 000068 000004 00 WA 0 0 1
[ 5] version PROGBITS 0000000000000000 00006c 000004 00 WA 0 0 4
[ 6] .symtab SYMTAB 0000000000000000 000070 000078 18 1 2 8
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
#
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1466064161-48553-2-git-send-email-wangnan0@huawei.com
[ s/dumpping/dumping/g ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
