Commit 003ca0fd2286 ("Refactor disassembler selection") in the binutils
repo, which changed the disassembler() function signature, so we must
use the feature test introduced in fb982666e3 ("tools/bpftool: fix
bpftool build with bintutils >= 2.9") to deal with that.
Committer testing:
After adding the missing function call to test-all.c, and:
FEATURE_CHECK_LDFLAGS-disassembler-four-args = -bfd -lopcodes
And the fallbacks for cases where we need -liberty and sometimes -lz to
tools/perf/Makefile.config, we get:
$ make -C tools/perf O=/tmp/build/perf install-bin
make: Entering directory '/home/acme/git/perf/tools/perf'
BUILD: Doing 'make -j8' parallel build
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... gtk2: [ on ]
... libaudit: [ on ]
... libbfd: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libperl: [ on ]
... libpython: [ on ]
... libslang: [ on ]
... libcrypto: [ on ]
... libunwind: [ on ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... get_cpuid: [ on ]
... bpf: [ on ]
... libaio: [ on ]
... disassembler-four-args: [ on ]
CC /tmp/build/perf/jvmti/libjvmti.o
CC /tmp/build/perf/builtin-bench.o
<SNIP>
$
$
The feature detection test-all.bin gets successfully built and linked:
$ ls -la /tmp/build/perf/feature/test-all.bin
-rwxrwxr-x. 1 acme acme 2680352 Mar 19 11:07 /tmp/build/perf/feature/test-all.bin
$ nm /tmp/build/perf/feature/test-all.bin | grep -w disassembler
0000000000061f90 T disassembler
$
Time to move on to the patches that make use of this disassembler()
routine in binutils's libopcodes.
Signed-off-by: Song Liu <songliubraving@fb.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Stanislav Fomichev <sdf@google.com>
Link: http://lkml.kernel.org/r/20190312053051.2690567-13-songliubraving@fb.com
[ split from a larger patch, added missing FEATURE_CHECK_LDFLAGS-disassembler-four-args ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Both libbfd and libopcodes are distributed with binutil-dev/devel. When
libbfd is present, it is OK to assume that libopcodes also present. This
has been a safe assumption for bpftool.
This patch adds -lopcodes to perf/Makefile.config. libopcodes will be
used in the next commit for BPF annotation.
Signed-off-by: Song Liu <songliubraving@fb.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stanislav Fomichev <sdf@google.com>
Cc: kernel-team@fb.com
Link: http://lkml.kernel.org/r/20190312053051.2690567-12-songliubraving@fb.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When the libcrypto feature test was added we forgot to add its
FEATURE_CHECK_LDFLAGS pointing to the library needed to link with the
test-all.bin feature test fast path binary, so even when it was
introduced we got this:
$ cat /tmp/build/perf/feature/test-all.make.output
/usr/bin/ld: /tmp/ccjKeJJU.o: in function `main_test_libcrypto':
/home/acme/git/perf/tools/build/feature/test-libcrypto.c:10: undefined reference to `MD5_Init'
/usr/bin/ld: /home/acme/git/perf/tools/build/feature/test-libcrypto.c:11: undefined reference to `MD5_Update'
/usr/bin/ld: /home/acme/git/perf/tools/build/feature/test-libcrypto.c:12: undefined reference to `MD5_Final'
/usr/bin/ld: /home/acme/git/perf/tools/build/feature/test-libcrypto.c:14: undefined reference to `SHA1'
collect2: error: ld returned 1 exit status
$ cat /tmp/build/perf/feature/test-libcrypto.
test-libcrypto.bin test-libcrypto.d test-libcrypto.make.output
$ cat /tmp/build/perf/feature/test-libcrypto.make.output
$
Fix it, so that we keep the fast path, which, at this point, will fail
with the unwind-ARCH feature tests, that will be fixed in a followup
patch:
$ make -C tools/perf O=/tmp/build/perf
... libcrypto: [ on ]
<SNIP>
$ cat /tmp/build/perf/feature/test-all.make.output
$ ldd /tmp/build/perf/feature/test-all.bin | grep libcrypto
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f9892805000)
$
$ grep libcrypto /tmp/build/perf/FEATURE-DUMP
feature-libcrypto=1
$
With the unwind-ARCH tests fixed, we now finally manage to get
test-all.bin built and linked with the features it tests, among them the
ones fixed in this patchkit:
$ ldd /tmp/build/perf/feature/test-all.bin | egrep 'unwind|crypto'
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f95cf2b8000)
libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007f95cf294000)
libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f95cf278000)
$
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Carl Love <cel@us.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: John McCutchan <johnmccutchan@google.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sonny Rao <sonnyrao@chromium.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Fixes: 8ee4646038 ("perf build: Add libcrypto feature detection")
Link: https://lkml.kernel.org/n/tip-rexc248jorf5b4l3qjn888cz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As it is not normally available on x86_64 not being tested on test-all.c
but being in FEATURE_TESTS_BASIC ends up implying that those features
are present, which leads to trying to link with those libraries and a
build failure now that test-all.c is finally again building
successfully:
/usr/bin/ld: cannot find -lunwind-x86
/usr/bin/ld: cannot find -lunwind-aarch64
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:199: /tmp/build/perf/plugin_jbd2.so] Error 1
make[3]: *** Waiting for unfinished jobs....
/usr/bin/ld: cannot find -lunwind-x86
/usr/bin/ld: cannot find -lunwind-aarch64
So remove those features from there and explicitely test them.
And then move this patch to just before the last one that allows this to
be exposed, so that we keep the tree bisectable.
With all this in place we get, at this point:
$ ldd /tmp/build/perf/feature/test-libunwind.bin
linux-vdso.so.1 (0x00007fffa09c6000)
libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007fbcf4451000)
libunwind.so.8 => /lib64/libunwind.so.8 (0x00007fbcf4435000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fbcf440c000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007fbcf43f2000)
libc.so.6 => /lib64/libc.so.6 (0x00007fbcf422c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbcf4211000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbcf4491000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbcf41ed000)
libz.so.1 => /lib64/libz.so.1 (0x00007fbcf41d3000)
$ cat /tmp/build/perf/feature/test-libunwind-x86.make.output
test-libunwind-x86.c:2:10: fatal error: libunwind-x86.h: No such file or directory
#include <libunwind-x86.h>
^~~~~~~~~~~~~~~~~
compilation terminated.
$ cat /tmp/build/perf/feature/test-libunwind-aarch64.make.output
test-libunwind-aarch64.c:2:10: fatal error: libunwind-aarch64.h: No such file or directory
#include <libunwind-aarch64.h>
^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
$
$ ldd ~/bin/perf | grep unwind
libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007f5ceb24b000)
libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f5ceb22f000)
$
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jean Pihet <jean.pihet@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Link: https://lkml.kernel.org/n/tip-vs6kwqsvwk7oxhs6z9mq87pp@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Since it is not yet that generally available, avoid testing for the
presence of libcoresight in the fast path test-all.bin feature test.
# dnf search opencsd
No matches found.
# dnf search OpenCSD
No matches found.
# cat /etc/fedora-release
Fedora release 29 (Twenty Nine)
#
I.e. right now, in my system test-all.bin is failing all the time since
Fedora29 doesn't have libopencsd available:
$ cat /tmp/build/perf/feature/test-all.make.output
In file included from test-all.c:174:
test-libopencsd.c:2:10: fatal error: opencsd/c_api/opencsd_c_api.h: No such file or directory
#include <opencsd/c_api/opencsd_c_api.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
See:
6ab2b762be ("perf build: Disable libbabeltrace check by default")
For the rationale, as soon as libopencsd becomes more generally packaged
and available, we do the same thing we did with babeltrace, enabling it
by default, as done in:
24787afbcd ("perf tools: Enable LIBBABELTRACE by default")
For now, to explicitely ask for opencsd, make sure you have it installed
and use:
make -C tools/perf CORESIGHT=1
The feature test output will be there as an empty file:
$ ls -la /tmp/build/perf/feature/test-libopencsd.make.output
Because the binary used for the feature check was successfully built:
$ ls -la /tmp/build/perf/feature/test-libopencsd.bin
-rwxrwxr-x. 1 acme acme 18336 Feb 12 14:49 /tmp/build/perf/feature/test-libopencsd.bin
$ ldd /tmp/build/perf/feature/test-libopencsd.bin
linux-vdso.so.1 (0x00007fffe18cc000)
libopencsd_c_api.so.0 => /lib64/libopencsd_c_api.so.0 (0x00007fb8e67f6000)
libopencsd.so.0 => /lib64/libopencsd.so.0 (0x00007fb8e676f000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb8e65a9000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb8e6411000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb8e628d000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb8e6272000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb8e6828000)
$
And the resulting perf binary will be linked with it:
-rw-rw-r--. 1 acme acme 0 Feb 12 14:49 /tmp/build/perf/feature/test-libopencsd.make.output
$ ldd ~/bin/perf | grep opencsd
libopencsd_c_api.so.0 => /lib64/libopencsd_c_api.so.0 (0x00007fd43097f000)
libopencsd.so.0 => /lib64/libopencsd.so.0 (0x00007fd4308f8000)
$
To make sure this gets built before pushing things upstream I have a
ubuntu:19.04-x-arm64 container that has:
[root@quaco x-arm64]# grep CORESIGHT Dockerfile
ENV EXTRA_MAKE_ARGS=CORESIGHT=1
[root@quaco x-arm64]#
So that I always build with libopencsd before pushing things upstream.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kim Phillips <kim.phillips@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Link: https://lkml.kernel.org/n/tip-20vyy39jw9jgrijesi30fgox@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Since we need it to resolve the AIO symbols, otherwise we fail with:
$ cat /tmp/build/perf/feature/test-all.make.output
/usr/bin/ld: /tmp/ccEqrj36.o: undefined reference to symbol 'aio_return64@@GLIBC_2.2.5'
/usr/bin/ld: //usr/lib64/librt.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
$
When we added the aio support in 'perf record' only the test-libaio.bin
target got the -lrt, i.e. the feature detection slow path. Fix it.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Fixes: 2a07d81474 ("tools build feature: Check if libaio is available")
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Current libbfd feature test unconditionally links against -liberty and -lz.
While it's required on some systems (e.g. opensuse), it's completely
unnecessary on the others, where only -lbdf is sufficient (debian).
This patch streamlines (and renames) the following feature checks:
feature-libbfd - only link against -lbfd (debian),
see commit 2cf9040714 ("perf tools: Fix bfd
dependency libraries detection")
feature-libbfd-liberty - link against -lbfd and -liberty
feature-libbfd-liberty-z - link against -lbfd, -liberty and -lz (opensuse),
see commit 280e7c48c3 ("perf tools: fix BFD
detection on opensuse")
(feature-liberty{,-z} were renamed to feature-libbfd-liberty{,z}
for clarity)
The main motivation is to fix this feature test for bpftool which is
currently broken on debian (libbfd feature shows OFF, but we still
unconditionally link against -lbfd and it works).
Tested on debian with only -lbfd installed (without -liberty); I'd
appreciate if somebody on the other systems can test this new detection
method.
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/4dfc634cfcfb236883971b5107cf3c28ec8a31be.1542328222.git.sdf@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There are systems such as the Android NDK API level 24 has the
open_memstream() function but doesn't provide a prototype, adding noise
to the build:
builtin-timechart.c: In function 'cat_backtrace':
builtin-timechart.c:486:2: warning: implicit declaration of function 'open_memstream' [-Wimplicit-function-declaration]
FILE *f = open_memstream(&p, &p_len);
^
builtin-timechart.c:486:2: warning: nested extern declaration of 'open_memstream' [-Wnested-externs]
builtin-timechart.c:486:12: warning: initialization makes pointer from integer without a cast
FILE *f = open_memstream(&p, &p_len);
^
Define a LACKS_OPEN_MEMSTREAM_PROTOTYPE define so that code needing that
can get a prototype.
Checked in the bionic git repo to be available since level 23:
https://android.googlesource.com/platform/bionic/+/master/libc/include/stdio.h#241
FILE* open_memstream(char** __ptr, size_t* __size_ptr) __INTRODUCED_IN(23);
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: https://lkml.kernel.org/n/tip-343ashae97e5bq6vizusyfno@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There are systems such as the Android NDK API level 24 has the
sigqueue() function but doesn't provide a prototype, adding noise to the
build:
util/evlist.c: In function 'perf_evlist__prepare_workload':
util/evlist.c:1494:4: warning: implicit declaration of function 'sigqueue' [-Wimplicit-function-declaration]
if (sigqueue(getppid(), SIGUSR1, val))
^
util/evlist.c:1494:4: warning: nested extern declaration of 'sigqueue' [-Wnested-externs]
Define a LACKS_SIGQUEUE_PROTOTYPE define so that code needing that can
get a prototype.
Checked in the bionic git repo to be available since level 23:
https://android.googlesource.com/platform/bionic/+/master/libc/include/signal.h#123
int sigqueue(pid_t __pid, int __signal, const union sigval __value) __INTRODUCED_IN(23);
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: https://lkml.kernel.org/n/tip-lmhpev1uni9kdrv7j29glyov@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In debian/ubuntu its libssl-dev, but for fedora/RHEL/Centos/etc its
openssl-devel, fix it.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 8ee4646038 ("perf build: Add libcrypto feature detection")
Link: https://lkml.kernel.org/n/tip-lnxqszts6aq2c9jy4b7mlnym@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The Compiled Method Load Record (cmlr) is JDK specific interface to
access JVM stack info. This makes the jvmti agent code not compile under
another jdk, which does not support that.
Separating jvmti cmlr check into special feature check, and adding
HAVE_JVMTI_CMLR macro to indicate that.
Mark cmlr code in jvmti/libjvmti.c with HAVE_JVMTI_CMLR, so we can
compile it on system without cmlr support.
This change makes the jvmti compile with java-1.8.0-ibm package. It's
without the line numbers support, but the rest works.
Adding NO_JVMTI_CMLR compile variable for testing.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ben Gainey <ben.gainey@arm.com>
Cc: Gustavo Luiz Duarte <gduarte@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/20181121154341.21521-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
A new 'perf bench epoll' will use this, and to disable it for older
systems, add a feature test for this API.
This is just a simple program that if successfully compiled, means that
the feature is present, at least at the library level, in a build that
sets the output directory to /tmp/build/perf (using O=/tmp/build/perf),
we end up with:
$ ls -la /tmp/build/perf/feature/test-eventfd*
-rwxrwxr-x. 1 acme acme 8176 Nov 21 15:58 /tmp/build/perf/feature/test-eventfd.bin
-rw-rw-r--. 1 acme acme 588 Nov 21 15:58 /tmp/build/perf/feature/test-eventfd.d
-rw-rw-r--. 1 acme acme 0 Nov 21 15:58 /tmp/build/perf/feature/test-eventfd.make.output
$ ldd /tmp/build/perf/feature/test-eventfd.bin
linux-vdso.so.1 (0x00007fff3bf3f000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa984061000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa984417000)
$ grep eventfd -A 2 -B 2 /tmp/build/perf/FEATURE-DUMP
feature-dwarf=1
feature-dwarf_getlocations=1
feature-eventfd=1
feature-fortify-source=1
feature-sync-compare-and-swap=1
$
The main thing here is that in the end we'll have -DHAVE_EVENTFD in
CFLAGS, and then the 'perf bench' entry needing that API can be
selectively pruned.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: https://lkml.kernel.org/n/tip-wkeldwob7dpx6jvtuzl8164k@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As the namespace support code will use this, which is not available in
some non _GNU_SOURCE libraries such as Android's bionic used in my
container build tests (r12b and r15c at the moment).
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: https://lkml.kernel.org/n/tip-x56ypm940pwclwu45d7jfj47@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When a build is run from something like a cron job, the user's $PATH is
rather minimal, of note, not including /usr/sbin in my own case. Because
of that, an automated rpm package build ultimately fails to find
libperf-jvmti.so, because somewhere within the build, this happens...
/bin/sh: alternatives: command not found
/bin/sh: alternatives: command not found
Makefile.config:849: No openjdk development package found, please install
JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
...and while the build continues, libperf-jvmti.so isn't built, and
things fall down when rpm tries to find all the %files specified. Exact
same system builds everything just fine when the job is launched from a
login shell instead of a cron job, since alternatives is in $PATH, so
openjdk is actually found.
The test required to get into this section of code actually specifies
the full path, as does a block just above it, so let's do that here too.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: William Cohen <wcohen@redhat.com>
Fixes: d4dfdf00d4 ("perf jvmti: Plug compilation into perf build")
Link: http://lkml.kernel.org/r/20180906221812.11167-1-jarod@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The perf tool build and install is controlled via a Makefile. The
'install' rule creates directories and copies files. Among them are
header files installed in /usr/lib/include/perf/bpf/.
However all listed examples are installing its header files in
/usr/lib/<tool-name>/...[/include]/header.h
and not in
/usr/lib/include/<tool-name>/.../header.h.
Background information:
Building the Fedora 28 glibc RPM on s390x and s390 fails on s390 (gcc
-m31) as gcc is not able to find header-files like stdbool.h.
In the glibc.spec file, you can see that glibc is configured with
"--with-headers". In this case, first -nostdinc is added to the CFLAGS
and then further include paths are added via -isystem. One of those
paths should contain header files like stdbool.h.
In order to get this path, gcc is invoked with:
- on Fedora 28 (with 4.18 kernel):
$ gcc -print-file-name=include
/usr/lib/gcc/s390x-redhat-linux/8/include
$ gcc -m31 -print-file-name=include
/usr/lib/gcc/s390x-redhat-linux/8/../../../../lib/include
=> If perf is installed, this is: /usr/lib/include
On my machine this directory is only containing the directory "perf".
If perf is not installed gcc returns: /usr/lib/gcc/s390x-redhat-linux/8/include
- on Ubuntu 18.04 (with 4.15 kernel):
$ gcc -print-file-name=include
/usr/lib/gcc/s390x-linux-gnu/7/include
$ gcc -m31 -print-file-name=include
/usr/lib/gcc/s390x-linux-gnu/7/include
=> gcc returns the correct path even if perf is installed.
In each case, the introduction of the subdirectory /usr/lib/include
leads to the regression that one can not build the glibc RPM for s390
anymore as gcc can not find headers like stdbool.h.
To remedy this install bpf.h to /usr/lib/perf/include/bpf/bpf.h
Output before using the command 'perf test -Fv 40':
echo '...[bpf-program-source]...' | /usr/bin/clang ... \
-I/root/lib/include/perf/bpf ...
^^^^^^^^^^^^
...
[root@p23lp27 perf]# perf test -F 40
40: BPF filter :
40.1: Basic BPF filtering : Ok
40.2: BPF pinning : Ok
40.3: BPF prologue generation : Ok
40.4: BPF relocation checker : Ok
[root@p23lp27 perf]#
Output after using command 'perf test -Fv 40':
echo '...[bpf-program-source]...' | /usr/bin/clang ... \
-I/root/lib/perf/include/bpf ...
^^^^^^^^^^^^
...
[root@p23lp27 perf]# perf test -F 40
40: BPF filter :
40.1: Basic BPF filtering : Ok
40.2: BPF pinning : Ok
40.3: BPF prologue generation : Ok
40.4: BPF relocation checker : Ok
[root@p23lp27 perf]#
Committer testing:
While the above 'perf test -F 40' (or 'perf test bpf') will allow us
to see that the correct path is now added via -I, to actually test this
we better try to use a bpf script that includes files in the changed
directory.
We have the files that now reside in /root/lib/perf/examples/bpf/ to do
just that:
# tail -8 /root/lib/perf/examples/bpf/5sec.c
#include <bpf.h>
int probe(hrtimer_nanosleep, rqtp->tv_sec)(void *ctx, int err, long sec)
{
return sec == 5;
}
license(GPL);
# perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 4
0.333 (4000.086 ms): sleep/9248 nanosleep(rqtp: 0x7ffc155f3300) = 0
# perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 5
0.287 ( ): sleep/9659 nanosleep(rqtp: 0x7ffeafe38200) ...
0.290 ( ): perf_bpf_probe:hrtimer_nanosleep:(ffffffff9911efe0) tv_sec=5
0.287 (5000.059 ms): sleep/9659 ... [continued]: nanosleep()) = 0
# perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 6
0.247 (5999.951 ms): sleep/10068 nanosleep(rqtp: 0x7fff2086d900) = 0
# perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 5.987
0.293 ( ): sleep/10489 nanosleep(rqtp: 0x7ffdd4fc10e0) ...
0.296 ( ): perf_bpf_probe:hrtimer_nanosleep:(ffffffff9911efe0) tv_sec=5
0.293 (5986.912 ms): sleep/10489 ... [continued]: nanosleep()) = 0
#
Suggested-by: Stefan Liebler <stli@linux.ibm.com>
Suggested-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Fixes: 1b16fffa38 ("perf llvm-utils: Add bpf include path to clang command line")
Link: http://lkml.kernel.org/r/20180731073254.91090-1-tmricht@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This should speed up accessing new system calls introduced with the
kernel rather than waiting for libaudit updates to include them.
It also enables users to specify wildcards, for example, perf trace -e
'open*', just like was already possible on x86, s390, and powerpc, which
means arm64 can now pass the "Check open filename arg using perf trace +
vfs_getname" test.
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20180706163454.f714b9ab49ecc8566a0b3565@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Builds started failing in Fedora on Python 3.7 with:
`.gnu.debuglto_.debug_macro' referenced in section
`.gnu.debuglto_.debug_macro' of
util/scripting-engines/trace-event-python.o: defined in discarded
section
In Fedora, Python 3.7 added -flto to the list of --cflags and since it
was only applied to util/scripting-engines/trace-event-python.c and
scripts/python/Perf-Trace-Util/Context.c, linking failed.
It's not the first time the addition of flags has broken builds: commit
c6707fdef7 ("perf tools: Fix up build in hardnened environments")
appears to have fixed a similar problem. "python-config --includes"
provides the proper -I flags and doesn't introduce additional CFLAGS.
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20180710154612.6285-1-jcline@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The first one is the bare minimum that bpf infrastructure accepts before
it expects actual events to be set up:
$ cat tools/perf/examples/bpf/empty.c
char _license[] __attribute__((section("license"), used)) = "GPL";
int _version __attribute__((section("version"), used)) = LINUX_VERSION_CODE;
$
If you remove that "version" line, then it will be refused with:
# perf trace -e tools/perf/examples/bpf/empty.c
event syntax error: 'tools/perf/examples/bpf/empty.c'
\___ Failed to load tools/perf/examples/bpf/empty.c from source: 'version' section incorrect or lost
(add -v to see detail)
Run 'perf list' for a list of valid events
Usage: perf trace [<options>] [<command>]
or: perf trace [<options>] -- <command> [<options>]
or: perf trace record [<options>] [<command>]
or: perf trace record [<options>] -- <command> [<options>]
-e, --event <event> event/syscall selector. use 'perf list' to list available events
#
The next ones will, step by step, show simple filters, then the needs
for headers will be made clear, it will be put in place and tested with
new examples, rinse, repeat.
Back to using this first one to test the perf+bpf infrastructure:
If we run it will fail, as no functions are present connecting with,
say, a tracepoint or a function using the kprobes or uprobes
infrastructure:
# perf trace -e tools/perf/examples/bpf/empty.c
WARNING: event parser found nothing
invalid or unsupported event: 'tools/perf/examples/bpf/empty.c'
Run 'perf list' for a list of valid events
Usage: perf trace [<options>] [<command>]
or: perf trace [<options>] -- <command> [<options>]
or: perf trace record [<options>] [<command>]
or: perf trace record [<options>] -- <command> [<options>]
-e, --event <event> event/syscall selector. use 'perf list' to list available events
#
But, if we set things up to dump the generated object file to a file,
and do this after having run 'make install', still on the developer's
$HOME directory:
# cat ~/.perfconfig
[llvm]
dump-obj = true
#
# perf trace -e ~acme/lib/examples/perf/bpf/empty.c
LLVM: dumping /home/acme/lib/examples/perf/bpf/empty.o
WARNING: event parser found nothing
invalid or unsupported event: '/home/acme/lib/examples/perf/bpf/empty.c'
<SNIP>
#
We can look at the dumped object file:
# ls -la ~acme/lib/examples/perf/bpf/empty.o
-rw-r--r--. 1 root root 576 May 4 12:10 /home/acme/lib/examples/perf/bpf/empty.o
# file ~acme/lib/examples/perf/bpf/empty.o
/home/acme/lib/examples/perf/bpf/empty.o: ELF 64-bit LSB relocatable, *unknown arch 0xf7* version 1 (SYSV), not stripped
# readelf -sw ~acme/lib/examples/perf/bpf/empty.o
Symbol table '.symtab' contains 3 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 3 _license
2: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 4 _version
#
# tools/bpf/bpftool/bpftool --pretty ~acme/lib/examples/perf/bpf/empty.o
null
#
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: https://lkml.kernel.org/n/tip-y7dkhakejz3013o0w21n98xd@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To be consistent with other HAVE_XXX_SUPPORT uses in Makefile.config,
this patch renames HAVE_SYSCALL_TABLE to HAVE_SYSCALL_TABLE_SUPPORT and
updates the C code accordingly.
Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
Suggested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1523269609-28824-3-git-send-email-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Give as examples of package names to install to have this built for
fedora and debian, to help the user a bit.
The part from 'e.g.:' onwards:
No openjdk development package found, please install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: William Cohen <wcohen@redhat.com>
Link: https://lkml.kernel.org/n/tip-edbi4r2pvzn7no6ebxbtczng@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In Makefile.config, to make all libraries flags have _SUPPORT suffix,
rename HAVE_DWARF_GETLOCATIONS to HAVE_DWARF_GETLOCATIONS_SUPPORT
Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
Suggested-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jin Yao <yao.jin@intel.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1522402036-22915-4-git-send-email-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For most of libraries, in perf.config, they are recorded with -DHAVE_XXX in
CFLAGS according to if the libraries are compiled-in. Then C code then will
know if the library is compiled-in or not.
While for glibc, no -DHAVE_GLIBC_SUPPORT exists.
For python and perl libraries, only -DNO_PYTHON and -DNO_LIBPERL exist.
To make the code more consistent, the patch creates -DHAVE_LIBPYTHON_SUPPORT
and -DHAVE_LIBPERL_SUPPORT if the python and perl libraries are compiled-in.
Since the existing flags -DNO_PYTHON and -DNO_LIBPERL are being used in many
places in C code, this patch doesn't remove them. In a follow-up patch, we will
recontruct the C code and then use HAVE_XXX instead.
v3:
Move 'CFLAGS += -DHAVE_LIBPYTHON_SUPPORT' and 'CFLAGS +=
-DHAVE_LIBPERL_SUPPORT' to other places to avoid duplicated feature checking.
v2:
Create -DHAVE_GLIBC_SUPPORT, -DHAVE_LIBPYTHON_SUPPORT and
-DHAVE_LIBPERL_SUPPORT.
Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jin Yao <yao.jin@intel.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1522402036-22915-3-git-send-email-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Based on prior work:
https://lkml.org/lkml/2014/5/6/395
and on how other arches add libdw unwind support. Includes support for
running the unwind test, e.g., on a system with only elfutils' libdw
0.170, the test now runs, and successfully:
$ ./perf test unwind
56: Test dwarf unwind : Ok
Originally-by: Jean Pihet <jean.pihet@linaro.org>
Reported-by: Christian Hansen <chansen3@cisco.com>
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20180308211030.4ee4a0d6ff6dc5cda1b567d4@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This should speed up accessing new system calls introduced with the
kernel rather than waiting for libaudit updates to include them.
It also enables users to specify wildcards, for example, perf trace -e
'open*', just like was already possible on x86 and s390.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20180129083417.31240-4-ravi.bangoria@linux.vnet.ibm.com
[ Do it for ppc32 as well ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The Open CoreSight Decoding Library (openCSD) is a free and open library
to decode traces collected by the CoreSight hardware infrastructure.
This patch adds the required mechanic to recognise the presence of the
openCSD library on a system and set up miscellaneous flags to be used in
the compilation of the trace decoding feature.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kim Phillips <kim.phillips@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Mike Leach <mike.leach@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Link: http://lkml.kernel.org/r/1516211539-5166-2-git-send-email-mathieu.poirier@linaro.org
Link: http://lkml.kernel.org/r/1516635644-24819-1-git-send-email-mathieu.poirier@linaro.org
[ Merged missing test-libopencsd.c file, provided later by Mathieu ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Change the Makefile and build process to no longer require audit-libs
interfaces when the architecture provides system call tables.
Committer notes:
Its not enough to hook into the NO_LIBAUDIT makefile block, we need to
define a CONFIG_TRACE that gets selected by both architectures
generating the syscall tables from the kernel headers and from detecting
the availability of libaudit.
With that in place we will not link against libaudit even if the
necessary files are available for that, in fact we will not even try to
detect its availability, speeding up a bit the feature detection phase.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Reviewed-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: linux-s390@vger.kernel.org
LPU-Reference: 1516352177-11106-6-git-send-email-brueckner@linux.vnet.ibm.com
Link: https://lkml.kernel.org/n/tip-j68lub6ipm8apvy52vd3l4cm@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Display the state of the rest of the features (FEATURE_TESTS_EXTRA) on a
'make VF=1' build. These features are detected manually by perf's
Makefile.config so they can't be displayed with the main list, but only
after we're done in Makefile.config.
$ make VF=1
BUILD: Doing 'make -j4' parallel build
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... gtk2: [ on ]
SNIP
... timerfd: [ on ]
... sched_getcpu: [ on ]
... sdt: [ on ]
... setns: [ on ]
extra features:
... bionic: [ OFF ]
... compile-32: [ on ]
... compile-x32: [ OFF ]
... cplus-demangle: [ on ]
... hello: [ OFF ]
... libbabeltrace: [ on ]
... liberty: [ on ]
... liberty-z: [ on ]
... libunwind-debug-frame: [ OFF ]
... libunwind-debug-frame-arm: [ OFF ]
... libunwind-debug-frame-aarch64: [ OFF ]
SNIP
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
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: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20180109092646.GB11520@krava
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There's no reason anymore to treat babel trace in a special way, because
a) we no longer display its state b) the needed babeltrace library is
now out and well adopted among distros.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20180107160356.28203-2-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
On s390, object files must be compiled with position-indepedent code in
order to be incrementally linked or linked to shared libraries.
Therefore, add -fPIC to the CFLAGS for s390 to ensure each object file
is built properly.
Reported-by: Jonathan Hermann <jonathan.hermann@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: linux s390 list <linux-s390@vger.kernel.org>
Link: https://lkml.kernel.org/r/20171207080951.GC4889@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This one made x86 always build with -fPIC, when the intention was for
s390 to be built that way, due to a rebase mistake.
Reported-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
This reverts commit 1dc4ddf112.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This should speed up accessing new system calls introduced with the
kernel rather than waiting for libaudit updates to include them.
It also enables users to specify wildcards, for example, perf trace -e
'open*', just like was already possible on x86.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Reviewed-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: linux-s390@vger.kernel.org
LPU-Reference: 1512635281-20733-2-git-send-email-brueckner@linux.vnet.ibm.com
Link: https://lkml.kernel.org/n/tip-htplh3nbrivi7g3cffbh4fsu@git.kernel.org
[ split from a larger patch ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
On Fedora systems the perl and python CFLAGS/LDFLAGS include the
hardened specs from redhat-rpm-config package. We apply them only for
perl/python objects, which makes them not compatible with the rest of
the objects and the build fails with:
/usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -f
+PIC
/usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile w
+ith -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile.perf:507: perf] Error 1
make[1]: *** [Makefile.perf:210: sub-make] Error 2
make: *** [Makefile:69: all] Error 2
Mainly it's caused by perl/python objects being compiled with:
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
which prevent the final link impossible, because it will check
for 'proper' objects with following option:
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20171204082437.GC30564@krava
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
On s390, object files must be compiled with position-indepedent code in
order to be incrementally linked or linked to shared libraries.
Therefore, add -fPIC to the CFLAGS for s390 to ensure each object file
is built properly.
Reported-by: Jonathan Hermann <jonathan.hermann@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: linux s390 list <linux-s390@vger.kernel.org>
LPU-Reference: 1512031765-9382-1-git-send-email-brueckner@linux.vnet.ibm.com
Link: https://lkml.kernel.org/n/tip-a8wga8hrl0d0r84cal96fmgv@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As 'perf bench futex wake-parallel" will use this, which is not
available in older systems such as versions of the android NDK used in
my container build tests (r12b and r15c at the moment).
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: James Yang <james.yang@arm.com
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kim Phillips <kim.phillips@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: https://lkml.kernel.org/n/tip-1i7iv54in4wj08lwo55b0pzv@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Using the shell function for perl CFLAGS retrieval instead of back
quotes (``). Both execute shell with the command, but the latter is more
explicit and seems to be the preferred way.
Also we don't have any other use of the back quotes in perf Makefiles.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20171108102739.30338-2-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
With support for perf_regs and libdw, you can record and report
call graphs for user space programs. Simply invoke perf with
the --call-graph=dwarf command line option.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
[brueckner: added dwfl_thread_state_register_pc() call]
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Reviewed-and-tested-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Prior to this patch, make scripts tested for CLANG with ifeq ($(CC),
clang), failing to detect CLANG binaries with different names. Fix it by
testing for the existence of __clang__ macro in the list of compiler
defined macros.
Signed-off-by: David Carrillo-Cisneros <davidcc@google.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Paul Turner <pjt@google.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/20170827075442.108534-5-davidcc@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
* libunwind-x86_64 must be linked before libunwind
* libunwind requires liblzma
* static libunwind conflicts with static libgcc_eh
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/150322917247.129799.14247751517961953155.stgit@buzz
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Fix feature test for static libdw: link required dependencies. Backends
of libebl are not statically linked thus libdl is required.
In Debian/Ubuntu libdw-dev includes libebl.a starting from 0.166-1.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/150322916720.129772.7959925864494283854.stgit@buzz
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
And provide an alternative implementation to keep perf building on older
distros as we're about to add initial support for namespaces.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Krister Johansen <kjlx@templeofstupid.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-bqdwijunhjlvps1ardykhw1i@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Porting PPC to libdw only needs an architecture-specific hook to move
the register state from perf to libdw.
The ARM and x86 architectures already use libdw, and it is useful to
have as much common code for the unwinder as possible. Mark Wielaard
has contributed a frame-based unwinder to libdw, so that unwinding works
even for binaries that do not have CFI information. In addition,
libunwind is always preferred to libdw by the build machinery so this
cannot introduce regressions on machines that have both libunwind and
libdw installed.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Milian Wolff <milian.wolff@kdab.com>
Acked-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/1496312681-20133-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
With commit: 0a943cb10c (tools build: Add HOSTARCH Makefile variable)
when building for ARCH=x86_64, ARCH=x86_64 is passed to perf instead of
ARCH=x86, so the perf build process searchs header files from
tools/arch/x86_64/include, which doesn't exist.
The following build failure is seen:
In file included from util/event.c:2:0:
tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No such file or directory
compilation terminated.
Fix this issue by using SRCARCH instead of ARCH in perf, just like the
main kernel Makefile and tools/objtool's.
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: Jan Stancek <jstancek@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 0a943cb10c ("tools build: Add HOSTARCH Makefile variable")
Link: http://lkml.kernel.org/r/1491793357-14977-2-git-send-email-jiada_wang@mentor.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The build of JVMTI depends on LIBELF (-lelf). Make Makefile.conf
check this dependendancy and notify user when not present.
v2: Comma nitpicking.
Signed-off-by: David Carrillo-Cisneros <davidcc@google.com>
Tested-by: Kim Phillips <kim.phillips@arm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Paul Turner <pjt@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Simon Que <sque@chromium.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20170412170745.26620-1-davidcc@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
( This is a rebased version of https://lkml.org/lkml/2017/2/7/662 )
Python's CC and link Makefile variables were not passed to feature
detection, causing feature detection to use system's Python rather than
PYTHON_CONFIG's one. This created a mismatch between the detected Python
support and the one actually used by perf when PYTHON_CONFIG is
specified.
Fix it by moving Python's variable initialization to before feature
detection and pass FLAGS_PYTHON_EMBED to Python's feature detection's
build target.
Signed-off-by: David Carrillo-Cisneros <davidcc@google.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Paul Turner <pjt@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Simon Que <sque@chromium.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20170412064919.92449-2-davidcc@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Instead of trying to go on adding more ifdef conditions, do a feature
test and define HAVE_SCHED_GETCPU_SUPPORT instead, then use it to
provide the prototype. No need to change the stub, as it is already a
__weak symbol.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-yge89er9g90sc0v6k0a0r5tr@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Gcc has a -spec option to override what options to pass to cc, etc, and
in some distros this is used, like in fedora, where we end up getting
this passed to gcc that makes clang, that doesn't have this option to
stop the build:
CC /tmp/build/perf/util/scripting-engines/trace-event-python.o
clang-4.0: error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Werror,-Wunused-command-line-argument]
So filter this out when the compiler used is clang, this way we
can build the python scripting support in tools/perf/.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-2gosxoiouf24pnlknp7w7q4z@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Song Liu
Arnaldo Carvalho de Melo
Stanislav Fomichev
Alexey Budankov
Jiri Olsa
Jarod Wilson
Thomas Richter
Kim Phillips
Jeremy Cline
Jin Yao
Jaroslav Škarvada
Ravi Bangoria
Mathieu Poirier
Hendrik Brueckner
Jiri Olsa
Ingo Molnar
Heiko Carstens
David Carrillo-Cisneros
Konstantin Khlebnikov
Paolo Bonzini
Jiada Wang