Commits such as 65dd297ac2 ("xfs: %pF is only for function
pointers") caused a regression because pretty_print() didn't support
%ps/%pS. The current %pf/%pF implementation in pretty_print() is what
%ps/%pS is supposed to do, so use the same code for %ps/%pS.
Addressing the incorrect %pf/%pF implementation is beyond the scope of
this patch.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Dave Chinner <david@fromorbit.com>
Link: http://lkml.kernel.org/r/20150831211637.GA12848@home.buserror.net
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Storing the actual tracing path mountpoint to display correct
error message hint ('Hint:' line). The error hint rediscovers
mountpoints, but it could be different from what we actually
used in tracing path.
Before we'd display debugfs mount even though tracefs was used:
$ perf record -e sched:sched_krava ls
event syntax error: 'sched:sched_krava'
\___ can't access trace events
Error: No permissions to read /sys/kernel/debug/tracing/events/sched/sched_krava
Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug'
...
After this change, correct mountpoint is displayed:
$ perf record -e sched:sched_krava ls
event syntax error: 'sched:sched_krava'
\___ can't access trace events
Error: No permissions to read /sys/kernel/debug/tracing/events/sched/sched_krava
Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing'
...
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Raphael Beamonte <raphael.beamonte@gmail.com>
Link: http://lkml.kernel.org/r/1442674027-19427-1-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:
User visible changes:
- Fix a segfault in 'perf probe' when removing uprobe events. (Masami Hiramatsu)
- Synthesize COMM event for workloads started from the command line in 'perf
record' so that we can have the pid->comm mapping before we get the real
PERF_RECORD_COMM switching from perf to the workload. (Namhyung Kim)
- Fix build tools/vm/ due to removal of tools/lib/api/fs/debugfs.h.
(Arnaldo Carvalho de Melo)
Infrastructure changes:
- Fix the make tarball targets by including the recently added err.h header in
the perf MANIFEST file. (Jiri Olsa)
- Don't assume that the event parser returns a non empty evlist. (Wang Nan)
- Add way to disambiguate feature detection state files, needed to use
tools/build feature detection for multiple components in a single O= output
dir, which will be the case with tools/perf/ and tools/lib/bpf/.
(Arnaldo Carvalho de Melo)
- Fixup FEATURE_{TESTS,DISPLAY} inversion in tools/lib/bpf/. (Arnaldo Carvalho de Melo)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
When a trace recorded on a 32-bit device is processed with a 64-bit
binary, the higher 32-bits of the address need to ignored.
The lack of this results in the output of the 64-bit pointer
value to the trace as the 32-bit address lookup fails in find_printk().
Before:
burn-1778 [003] 548.600305: bputs: 0xc0046db2s: 2cec5c058d98c
After:
burn-1778 [003] 548.600305: bputs: 0xc0046db2s: RT throttling activated
The problem occurs in PRINT_FIELD when the field is recognized as a
pointer to a string (of the type const char *)
Heterogeneous architectures cases below can arise and should be handled:
* Traces recorded using 32-bit addresses processed on a 64-bit machine
* Traces recorded using 64-bit addresses processed on a 32-bit machine
Reported-by: Juri Lelli <juri.lelli@arm.com>
Signed-off-by: Kapileshwar Singh <kapileshwar.singh@arm.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Javi Merino <javi.merino@arm.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When building tools/lib/bpf as part of the tools/perf/ build process,
which will happend when we introduce a patch wiring that up, we end up
stomping on the feature detection caching mechanism, that uses a file in
the output directory (O=) that is shared by libbpf and perf to check if
something changed from one build to another that requires redoing the
feature detection process.
By using the recently introduced FEATURE_USER tools/build/ knob, we can
avoid that:
Before, every make invokation would run the feature detection:
$ make O=/tmp/build/perf -C tools/perf
make: Entering directory '/home/git/linux/tools/perf'
Auto-detecting system features:
... dwarf: [ on ]
... glibc: [ on ]
<SNIP>
... get_cpuid: [ on ]
... bpf: [ on ]
GEN perf-archive
GEN perf-with-kcore
Auto-detecting system features:
... libelf: [ on ]
... bpf: [ on ]
<SNIP>
After:
$ make O=/tmp/build/perf -C tools/perf
make: Entering directory '/home/git/linux/tools/perf'
BUILD: Doing 'make -j4' parallel build
make: Leaving directory '/home/git/linux/tools/perf'
$
Because we now have two different feature detection state files:
$ ls -la /tmp/build/perf/FEATURE-DUMP*
-rw-rw-r--. 1 acme acme 338 Sep 21 17:25 /tmp/build/perf/FEATURE-DUMP
-rw-rw-r--. 1 acme acme 33 Sep 21 17:25 /tmp/build/perf/FEATURE-DUMP.libbpf
$
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: pi3orama@163.com
Fixes: 1b76c13e4b ("bpf tools: Introduce 'bpf' library and add bpf feature check")
Link: http://lkml.kernel.org/n/tip-s6ev9wfqy7pvvs58emys2g90@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When libbpf was introduced it wrongly asked for the "libelf" and "bpf"
feature tests to be performed (via FEATURE_TESTS), while asking that
"libbpf", "libelf-mmap", "libelf-getphdrnum" and "bpf" to have the
result of its respective tests to be displayed (via FEATURE_DISPLAY).
Due to another recently bug fixed in the tools/build/ infrastructure
("tools build: Fixup feature detection display function name") the
results for the entries in the FEATURE_DISPLAY, for this case, were
appearing as all succeeding, when two of them (the ones only on the
DISPLAY) were not even being performed.
Before:
$ make -C tools/lib/bpf/
make: Entering directory '/home/git/linux/tools/lib/bpf'
Auto-detecting system features:
... libelf: [ on ]
... libelf-getphdrnum: [ OFF ]
... libelf-mmap: [ OFF ]
... bpf: [ on ]
<SNIP>
After, with FEATURE_TESTS == FEATURE_DISPLAY:
Auto-detecting system features:
... libelf: [ on ]
... libelf-getphdrnum: [ on ]
... libelf-mmap: [ on ]
... bpf: [ on ]
<SNIP>
I just inverted, so that it tests the four features but displays just
the libelf and mmap ones, to make it more compact. So it becomes:
$ make -C tools/lib/bpf/
make: Entering directory '/home/git/linux/tools/lib/bpf'
Auto-detecting system features:
... libelf: [ on ]
... bpf: [ on ]
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: pi3orama@163.com
Fixes: 1b76c13e4b ("bpf tools: Introduce 'bpf' library and add bpf feature check")
Link: http://lkml.kernel.org/n/tip-y4bd59e6j9rzzojiyeqrg2jq@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
