CROSS_COMPILE can be considered as standard definition for toolchain prefix
when cross-compiling. Use it here.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.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>
Adds two tests. One is a simple test to ensure that the new registers
LMRR and LMSER are properly maintained. The other actually uses the
existing EBB test infrastructure to test that LMRR and LMSER behave as
documented.
Signed-off-by: Jack Miller <jack@codezen.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Pull tracing fixes from Steven Rostedt:
"Two fixes for the tracing system:
- When trace_printk() is used with a non constant format descriptor,
it adds a NULL pointer into the trace format section, and the code
isn't prepared to deal with it. This bug appeared by a change that
was added in v3.5.
- The ftracetest (selftests section) can't handle testing histograms
when histograms are not configured. Currently it shows that they
fail the test, when they should state that they are unsupported.
This bug was added in the 4.7 merge window with the addition of the
historgram code"
* tag 'trace-v4.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftracetest: Fix hist unsupported result in hist selftests
tracing: Handle NULL formats in hold_module_trace_bprintk_format()
We want the fixes in here, and we can resolve a merge issue in
drivers/iio/industrialio-trigger.c
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When histograms are not configured in the kernel, the ftracetest histogram
selftests should return "unsupported" and not "Failed". To detect this, the
test scripts have:
FEATURE=`grep hist events/sched/sched_process_fork/trigger`
if [ -z "$FEATURE" ]; then
echo "hist trigger is not supported"
exit_unsupported
fi
The problem is that '-e' is in effect and any error will cause the program
to terminate. The grep for 'hist' fails, because it is not compiled it (thus
unsupported), but because grep has an error code for failing to find the
string, it causes the program to terminate, and is marked as a failed test.
Namhyung Kim recommended to test for the "hist" file located in
events/sched/sched_process_fork/hist instead, as it is more inline with the
other checks. As the hist file is only created if the histogram feature is
enabled, that is a valid check.
Link: http://lkml.kernel.org/r/20160523151538.4ea9ce0c@gandalf.local.home
Suggested-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Fixes: 76929ab51f ("kselftests/ftrace: Add hist trigger testcases")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Fail building nfit_test.ko when the configuration is missing pfn device
support.
Reported-by: Megha Dey <megha.dey@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Pull virtio docs and tests from Michael Tsirkin:
"This merely has some documentation and a new test, seems safe to
merge"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
tools/virtio: add noring tool
tools/virtio/ringtest: fix run-on-all.sh to work without /dev/cpu
tools/virtio/ringtest: add usage example to README
MAINTAINERS: Add file patterns for virtio device tree bindings
The execveat test try to exec the Makefile file and expect an EACCES
results. When running the test in the installed destination it would
fail with ENOENT since the file is not there.
Add Makefile to the TEST_FILES list so it's copied at install time.
Signed-off-by: Yannick Brosseau <scientist@fb.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
