summaryrefslogtreecommitdiff
path: root/tools/build/feature/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2022-10-25perf bpf: Fix build with libbpf 0.7.0 by checking if ↵Arnaldo Carvalho de Melo1-0/+4
bpf_program__set_insns() is available During the transition to libbpf 1.0 some functions that perf used were deprecated and finally removed from libbpf, so bpf_program__set_insns() was introduced for perf to continue to use its bpf loader. But when build with LIBBPF_DYNAMIC=1 we now need to check if that function is available so that perf can build with older libbpf versions, even if the end result is emitting a warning to the user that the use of the perf BPF loader requires a newer libbpf, since bpf_program__set_insns() touches libbpf objects internal state. This affects only 'perf trace' when using bpf C code or pre-compiled bytecode as an event. Noticed on RHEL9, that has libbpf 0.7.0, where bpf_program__set_insns() isn't available. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-08-10tools, build: Retry detection of bfd-related featuresRoberto Sassu1-5/+9
While separate features have been defined to determine which linking flags are required to use libbfd depending on the distribution (libbfd, libbfd-liberty and libbfd-liberty-z), the same has not been done for other features requiring linking to libbfd. For example, disassembler-four-args requires linking to libbfd too, but it should use the right linking flags. If not all the required ones are specified, e.g. -liberty, detection will always fail even if the feature is available. Instead of creating new features, similarly to libbfd, simply retry detection with the different set of flags until detection succeeds (or fails, if the libraries are missing). In this way, feature detection is transparent for the users of this building mechanism (e.g. perf), and those users don't have for example to set an appropriate value for the FEATURE_CHECK_LDFLAGS-disassembler-four-args variable. The number of retries and features for which the retry mechanism is implemented is low enough to make the increase in the complexity of Makefile negligible. Tested with perf and bpftool on Ubuntu 20.04.4 LTS, Fedora 36 and openSUSE Tumbleweed. Committer notes: Do the retry for disassembler-init-styled as well. Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andres Freund <andres@anarazel.de> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: John Fastabend <john.fastabend@gmail.com> Cc: KP Singh <kpsingh@kernel.org> Cc: Martin KaFai Lau <martin.lau@linux.dev> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Nick Terrell <terrelln@fb.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Quentin Monnet <quentin@isovalent.com> Cc: Song Liu <song@kernel.org> Cc: Stanislav Fomichev <sdf@google.com> Cc: bpf@vger.kernel.org Cc: llvm@lists.linux.dev Link: https://lore.kernel.org/r/20220719170555.2576993-1-roberto.sassu@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-08-01tools build: Add feature test for init_disassemble_info API changesAndres Freund1-0/+4
binutils changed the signature of init_disassemble_info(), which now causes compilation failures for tools/{perf,bpf}, e.g. on debian unstable. Relevant binutils commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=60a3da00bd5407f07 This commit adds a feature test to detect the new signature. Subsequent commits will use it to fix the build failures. Signed-off-by: Andres Freund <andres@anarazel.de> Acked-by: Quentin Monnet <quentin@isovalent.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Ben Hutchings <benh@debian.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Quentin Monnet <quentin@isovalent.com> Cc: Sedat Dilek <sedat.dilek@gmail.com> Cc: bpf@vger.kernel.org Link: http://lore.kernel.org/lkml/20220622181918.ykrs5rsnmx3og4sv@alap3.anarazel.de Link: https://lore.kernel.org/r/20220801013834.156015-2-andres@anarazel.de Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-05-26perf build: Stop using __weak bpf_map_create() to handle older libbpf versionsArnaldo Carvalho de Melo1-0/+4
By adding a feature test for bpf_map_create() and providing a fallback if it isn't present in older versions of libbpf. This also fixes the build with torvalds/master at this point: $ git log --oneline -5 torvalds/master babf0bb978e3c9fc (torvalds/master) Merge tag 'xfs-5.19-for-linus' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux e375780b631a5fc2 Merge tag 'fsnotify_for_v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs 8b728edc5be16179 Merge tag 'fs_for_v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs 3f306ea2e18568f6 Merge tag 'dma-mapping-5.19-2022-05-25' of git://git.infradead.org/users/hch/dma-mapping fbe86daca0ba878b Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi $ Coping with: $ git log --oneline -2 d16495a982324f75 d16495a982324f75 libbpf: remove bpf_create_map*() APIs e2371b1632b1c61c libbpf: start 1.0 development cycle $ As the __weak function fails to build as it calls the now removed bpf_create_map() API. Testing: $ rpm -q libbpf-devel libbpf-devel-0.4.0-2.fc35.x86_64 $ $ make -C tools/perf BUILD_BPF_SKEL=1 LIBBPF_DYNAMIC=1 O=/tmp/build/perf install-bin $ cat /tmp/build/perf/feature/test-libbpf-bpf_map_create.make.output test-libbpf-bpf_map_create.c: In function ‘main’: test-libbpf-bpf_map_create.c:6:16: error: implicit declaration of function ‘bpf_map_create’; did you mean ‘bpf_map_freeze’? [-Werror=implicit-function-declaration] 6 | return bpf_map_create(0 /* map_type */, NULL /* map_name */, 0, /* key_size */, | ^~~~~~~~~~~~~~ | bpf_map_freeze test-libbpf-bpf_map_create.c:6:87: error: expected expression before ‘,’ token 6 | return bpf_map_create(0 /* map_type */, NULL /* map_name */, 0, /* key_size */, | ^ cc1: all warnings being treated as errors $ $ objdump -dS /tmp/build/perf/perf | grep '<bpf_map_create>:' -A20 000000000058b290 <bpf_map_create>: { 58b290: 55 push %rbp 58b291: 48 89 e5 mov %rsp,%rbp 58b294: 48 83 ec 10 sub $0x10,%rsp 58b298: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax 58b29f: 00 00 58b2a1: 48 89 45 f8 mov %rax,-0x8(%rbp) 58b2a5: 31 c0 xor %eax,%eax return bpf_create_map(map_type, key_size, value_size, max_entries, 0); 58b2a7: 48 8b 45 f8 mov -0x8(%rbp),%rax 58b2ab: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax 58b2b2: 00 00 58b2b4: 75 10 jne 58b2c6 <bpf_map_create+0x36> } 58b2b6: c9 leave 58b2b7: 89 d6 mov %edx,%esi 58b2b9: 89 ca mov %ecx,%edx 58b2bb: 44 89 c1 mov %r8d,%ecx return bpf_create_map(map_type, key_size, value_size, max_entries, 0); 58b2be: 45 31 c0 xor %r8d,%r8d $ Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ian Rogers <irogers@google.com> Cc: Ilya Leoshkevich <iii@linux.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Song Liu <songliubraving@fb.com> Cc: Sumanth Korikkar <sumanthk@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Richter <tmricht@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Link: http://lore.kernel.org/linux-perf-users/Yo+XvQNKL4K5khl2@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-05-26perf build: Stop using __weak btf__raw_data() to handle older libbpf versionsJiri Olsa1-0/+4
By adding a feature test for btf__raw_data() and providing a fallback if it isn't present in older versions of libbpf. Committer testing: $ rpm -q libbpf-devel libbpf-devel-0.4.0-2.fc35.x86_64 $ make -C tools/perf LIBBPF_DYNAMIC=1 O=/tmp/build/perf install-bin $ cat /tmp/build/perf/feature/test-libbpf-btf__raw_data.make.output test-libbpf-btf__raw_data.c: In function ‘main’: test-libbpf-btf__raw_data.c:6:9: error: implicit declaration of function ‘btf__raw_data’; did you mean ‘btf__get_raw_data’? [-Werror=implicit-function-declaration] 6 | btf__raw_data(NULL /* btf_ro */, NULL /* size */); | ^~~~~~~~~~~~~ | btf__get_raw_data cc1: all warnings being treated as errors $ objdump -dS /tmp/build/perf/perf | grep '<btf__raw_data>:' -A20 00000000005b3050 <btf__raw_data>: { 5b3050: 55 push %rbp 5b3051: 48 89 e5 mov %rsp,%rbp 5b3054: 48 83 ec 10 sub $0x10,%rsp 5b3058: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax 5b305f: 00 00 5b3061: 48 89 45 f8 mov %rax,-0x8(%rbp) 5b3065: 31 c0 xor %eax,%eax return btf__get_raw_data(btf_ro, size); 5b3067: 48 8b 45 f8 mov -0x8(%rbp),%rax 5b306b: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax 5b3072: 00 00 5b3074: 75 06 jne 5b307c <btf__raw_data+0x2c> } 5b3076: c9 leave return btf__get_raw_data(btf_ro, size); 5b3077: e9 14 99 e5 ff jmp 40c990 <btf__get_raw_data@plt> 5b307c: e8 af a7 e5 ff call 40d830 <__stack_chk_fail@plt> 5b3081: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) 5b3088: 00 00 00 00 $ Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ian Rogers <irogers@google.com> Cc: Ilya Leoshkevich <iii@linux.ibm.com> Cc: Sumanth Korikkar <sumanthk@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Richter <tmricht@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Link: http://lore.kernel.org/linux-perf-users/YozLKby7ITEtchC9@krava Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-05-26perf build: Stop using __weak bpf_object__next_map() to handle older libbpf ↵Jiri Olsa1-0/+4
versions By adding a feature test for bpf_object__next_map() and providing a fallback if it isn't present in older versions of libbpf. Committer testing: $ rpm -q libbpf-devel libbpf-devel-0.4.0-2.fc35.x86_64 $ make -C tools/perf LIBBPF_DYNAMIC=1 O=/tmp/build/perf install-bin $ cat /tmp/build/perf/feature/test-libbpf-bpf_object__next_map.make.output test-libbpf-bpf_object__next_map.c: In function ‘main’: test-libbpf-bpf_object__next_map.c:6:9: error: implicit declaration of function ‘bpf_object__next_map’; did you mean ‘bpf_object__next’? [-Werror=implicit-function-declaration] 6 | bpf_object__next_map(NULL /* obj */, NULL /* prev */); | ^~~~~~~~~~~~~~~~~~~~ | bpf_object__next cc1: all warnings being treated as errors $ $ objdump -dS /tmp/build/perf/perf | grep '<bpf_object__next_map>:' -A20 00000000005b2e00 <bpf_object__next_map>: { 5b2e00: 55 push %rbp 5b2e01: 48 89 e5 mov %rsp,%rbp 5b2e04: 48 83 ec 10 sub $0x10,%rsp 5b2e08: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax 5b2e0f: 00 00 5b2e11: 48 89 45 f8 mov %rax,-0x8(%rbp) 5b2e15: 31 c0 xor %eax,%eax return bpf_map__next(prev, obj); 5b2e17: 48 8b 45 f8 mov -0x8(%rbp),%rax 5b2e1b: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax 5b2e22: 00 00 5b2e24: 75 0f jne 5b2e35 <bpf_object__next_map+0x35> } 5b2e26: c9 leave 5b2e27: 49 89 f8 mov %rdi,%r8 5b2e2a: 48 89 f7 mov %rsi,%rdi return bpf_map__next(prev, obj); 5b2e2d: 4c 89 c6 mov %r8,%rsi 5b2e30: e9 cb b1 e5 ff jmp 40e000 <bpf_map__next@plt> $ Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ian Rogers <irogers@google.com> Cc: Ilya Leoshkevich <iii@linux.ibm.com> Cc: Sumanth Korikkar <sumanthk@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Richter <tmricht@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Link: http://lore.kernel.org/linux-perf-users/YozLKby7ITEtchC9@krava Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-05-26perf build: Stop using __weak bpf_object__next_program() to handle older ↵Jiri Olsa1-0/+4
libbpf versions By adding a feature test for bpf_object__next_program() and providing a fallback if it isn't present in older versions of libbpf. Committer testing: $ rpm -q libbpf-devel libbpf-devel-0.4.0-2.fc35.x86_64 $ make -C tools/perf LIBBPF_DYNAMIC=1 O=/tmp/build/perf install-bin $ cat /tmp/build/perf/feature/test-libbpf-bpf_object__next_program.make.output test-libbpf-bpf_object__next_program.c: In function ‘main’: test-libbpf-bpf_object__next_program.c:6:9: error: implicit declaration of function ‘bpf_object__next_program’; did you mean ‘bpf_object__unpin_programs’? [-Werror=implicit-function-declaration] 6 | bpf_object__next_program(NULL /* obj */, NULL /* prev */); | ^~~~~~~~~~~~~~~~~~~~~~~~ | bpf_object__unpin_programs cc1: all warnings being treated as errors $ $ objdump -dS /tmp/build/perf/perf | grep '<bpf_object__next_program>:' -A20 00000000005b2dc0 <bpf_object__next_program>: { 5b2dc0: 55 push %rbp 5b2dc1: 48 89 e5 mov %rsp,%rbp 5b2dc4: 48 83 ec 10 sub $0x10,%rsp 5b2dc8: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax 5b2dcf: 00 00 5b2dd1: 48 89 45 f8 mov %rax,-0x8(%rbp) 5b2dd5: 31 c0 xor %eax,%eax return bpf_program__next(prev, obj); 5b2dd7: 48 8b 45 f8 mov -0x8(%rbp),%rax 5b2ddb: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax 5b2de2: 00 00 5b2de4: 75 0f jne 5b2df5 <bpf_object__next_program+0x35> } 5b2de6: c9 leave 5b2de7: 49 89 f8 mov %rdi,%r8 5b2dea: 48 89 f7 mov %rsi,%rdi return bpf_program__next(prev, obj); 5b2ded: 4c 89 c6 mov %r8,%rsi 5b2df0: e9 3b b4 e5 ff jmp 40e230 <bpf_program__next@plt> $ Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ian Rogers <irogers@google.com> Cc: Ilya Leoshkevich <iii@linux.ibm.com> Cc: Sumanth Korikkar <sumanthk@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Richter <tmricht@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Link: http://lore.kernel.org/linux-perf-users/YozLKby7ITEtchC9@krava Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-05-26perf build: Stop using __weak bpf_prog_load() to handle older libbpf versionsJiri Olsa1-0/+4
By adding a feature test for bpf_prog_load() and providing a fallback if it isn't present in older versions of libbpf. Committer testing: $ rpm -q libbpf-devel libbpf-devel-0.4.0-2.fc35.x86_64 $ make -C tools/perf LIBBPF_DYNAMIC=1 O=/tmp/build/perf install-bin $ cat /tmp/build/perf/feature/test-libbpf-bpf_prog_load.make.output test-libbpf-bpf_prog_load.c: In function ‘main’: test-libbpf-bpf_prog_load.c:6:16: error: implicit declaration of function ‘bpf_prog_load’ [-Werror=implicit-function-declaration] 6 | return bpf_prog_load(0 /* prog_type */, NULL /* prog_name */, | ^~~~~~~~~~~~~ cc1: all warnings being treated as errors $ $ objdump -dS /tmp/build/perf/perf | grep '<bpf_prog_load>:' -A20 00000000005b2d70 <bpf_prog_load>: { 5b2d70: 55 push %rbp 5b2d71: 48 89 ce mov %rcx,%rsi 5b2d74: 4c 89 c8 mov %r9,%rax 5b2d77: 49 89 d2 mov %rdx,%r10 5b2d7a: 4c 89 c2 mov %r8,%rdx 5b2d7d: 48 89 e5 mov %rsp,%rbp 5b2d80: 48 83 ec 18 sub $0x18,%rsp 5b2d84: 64 48 8b 0c 25 28 00 mov %fs:0x28,%rcx 5b2d8b: 00 00 5b2d8d: 48 89 4d f8 mov %rcx,-0x8(%rbp) 5b2d91: 31 c9 xor %ecx,%ecx return bpf_load_program(prog_type, insns, insn_cnt, license, 5b2d93: 41 8b 49 5c mov 0x5c(%r9),%ecx 5b2d97: 51 push %rcx 5b2d98: 4d 8b 49 60 mov 0x60(%r9),%r9 5b2d9c: 4c 89 d1 mov %r10,%rcx 5b2d9f: 44 8b 40 1c mov 0x1c(%rax),%r8d 5b2da3: e8 f8 aa e5 ff call 40d8a0 <bpf_load_program@plt> } $ Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ian Rogers <irogers@google.com> Cc: Ilya Leoshkevich <iii@linux.ibm.com> Cc: Sumanth Korikkar <sumanthk@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Richter <tmricht@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Link: http://lore.kernel.org/linux-perf-users/YozLKby7ITEtchC9@krava Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-05-20perf build: Fix check for btf__load_from_kernel_by_id() in libbpfArnaldo Carvalho de Melo1-0/+4
Avi Kivity reported a problem where the __weak btf__load_from_kernel_by_id() in tools/perf/util/bpf-event.c was being used and it called btf__get_from_id() in tools/lib/bpf/btf.c that in turn called back to btf__load_from_kernel_by_id(), resulting in an endless loop. Fix this by adding a feature test to check if btf__load_from_kernel_by_id() is available when building perf with LIBBPF_DYNAMIC=1, and if not then provide the fallback to the old btf__get_from_id(), that doesn't call back to btf__load_from_kernel_by_id() since at that time it didn't exist at all. Tested on Fedora 35 where we have libbpf-devel 0.4.0 with LIBBPF_DYNAMIC where we don't have btf__load_from_kernel_by_id() and thus its feature test fail, not defining HAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID: $ cat /tmp/build/perf-urgent/feature/test-libbpf-btf__load_from_kernel_by_id.make.output test-libbpf-btf__load_from_kernel_by_id.c: In function ‘main’: test-libbpf-btf__load_from_kernel_by_id.c:6:16: error: implicit declaration of function ‘btf__load_from_kernel_by_id’ [-Werror=implicit-function-declaration] 6 | return btf__load_from_kernel_by_id(20151128, NULL); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors $ $ nm /tmp/build/perf-urgent/perf | grep btf__load_from_kernel_by_id 00000000005ba180 T btf__load_from_kernel_by_id $ $ objdump --disassemble=btf__load_from_kernel_by_id -S /tmp/build/perf-urgent/perf /tmp/build/perf-urgent/perf: file format elf64-x86-64 <SNIP> 00000000005ba180 <btf__load_from_kernel_by_id>: #include "record.h" #include "util/synthetic-events.h" #ifndef HAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID struct btf *btf__load_from_kernel_by_id(__u32 id) { 5ba180: 55 push %rbp 5ba181: 48 89 e5 mov %rsp,%rbp 5ba184: 48 83 ec 10 sub $0x10,%rsp 5ba188: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax 5ba18f: 00 00 5ba191: 48 89 45 f8 mov %rax,-0x8(%rbp) 5ba195: 31 c0 xor %eax,%eax struct btf *btf; #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations" int err = btf__get_from_id(id, &btf); 5ba197: 48 8d 75 f0 lea -0x10(%rbp),%rsi 5ba19b: e8 a0 57 e5 ff call 40f940 <btf__get_from_id@plt> 5ba1a0: 89 c2 mov %eax,%edx #pragma GCC diagnostic pop return err ? ERR_PTR(err) : btf; 5ba1a2: 48 98 cltq 5ba1a4: 85 d2 test %edx,%edx 5ba1a6: 48 0f 44 45 f0 cmove -0x10(%rbp),%rax } <SNIP> Fixes: 218e7b775d368f38 ("perf bpf: Provide a weak btf__load_from_kernel_by_id() for older libbpf versions") Reported-by: Avi Kivity <avi@scylladb.com> Link: https://lore.kernel.org/linux-perf-users/f0add43b-3de5-20c5-22c4-70aff4af959f@scylladb.com Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/linux-perf-users/YobjjFOblY4Xvwo7@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-04-09tools build: Filter out options and warnings not supported by clangArnaldo Carvalho de Melo1-0/+7
These make the feature check fail when using clang, so remove them just like is done in tools/perf/Makefile.config to build perf itself. Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config when building with clang is also necessary to avoid these warnings turned into errors (-Werror): CC /tmp/build/perf/util/scripting-engines/trace-event-perl.o In file included from util/scripting-engines/trace-event-perl.c:35: In file included from /usr/lib64/perl5/CORE/perl.h:4085: In file included from /usr/lib64/perl5/CORE/hv.h:659: In file included from /usr/lib64/perl5/CORE/hv_func.h:34: In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4: /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro] ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32' #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START { \ ^~~~~~~~~~ /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START' # define STMT_START (void)( /* gcc supports "({ STATEMENTS; })" */ ^ /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32' #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START { \ ^ /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro] ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32' v ^= (v>>23); \ ^ /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32' } STMT_END ^~~~~~~~ /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END' # define STMT_END ) ^ Please refer to the discussion on the Link: tag below, where Nathan clarifies the situation: <quote> acme> And then get to the problems at the end of this message, which seem acme> similar to the problem described here: acme> acme> From Nathan Chancellor <> acme> Subject [PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO acme> acme> https://lkml.org/lkml/2020/9/1/135 acme> acme> So perhaps in this case its better to disable that acme> -Werror,-Wcompound-token-split-by-macro when building with clang? Yes, I think that is probably the best solution. As far as I can tell, at least in this file and context, the warning appears harmless, as the "create a GNU C statement expression from two different macros" is very much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS. The warning is fixed in upstream Perl by just avoiding creating GNU C statement expressions using STMT_START and STMT_END: https://github.com/Perl/perl5/issues/18780 https://github.com/Perl/perl5/pull/18984 If I am reading the source code correctly, an alternative to disabling the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it seems like that might end up impacting more than just this site, according to the issue discussion above. </quote> Based-on-a-patch-by: Sedat Dilek <sedat.dilek@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # Debian/Selfmade LLVM-14 (x86-64) Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Fangrui Song <maskray@google.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Keeping <john@metanate.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Link: http://lore.kernel.org/lkml/YkxWcYzph5pC1EK8@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-04-09tools build: Use $(shell ) instead of `` to get embedded libperl's ccoptsArnaldo Carvalho de Melo1-1/+1
Just like its done for ldopts and for both in tools/perf/Makefile.config. Using `` to initialize PERL_EMBED_CCOPTS somehow precludes using: $(filter-out SOMETHING_TO_FILTER,$(PERL_EMBED_CCOPTS)) And we need to do it to allow for building with versions of clang where some gcc options selected by distros are not available. Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # Debian/Selfmade LLVM-14 (x86-64) Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Fangrui Song <maskray@google.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Keeping <john@metanate.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Link: http://lore.kernel.org/lkml/YktYX2OnLtyobRYD@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-12-07tools build: Remove needless libpython-version feature check that breaks ↵Arnaldo Carvalho de Melo1-4/+0
test-all fast path Since 66dfdff03d196e51 ("perf tools: Add Python 3 support") we don't use the tools/build/feature/test-libpython-version.c version in any Makefile feature check: $ find tools/ -type f | xargs grep feature-libpython-version $ The only place where this was used was removed in 66dfdff03d196e51: - ifneq ($(feature-libpython-version), 1) - $(warning Python 3 is not yet supported; please set) - $(warning PYTHON and/or PYTHON_CONFIG appropriately.) - $(warning If you also have Python 2 installed, then) - $(warning try something like:) - $(warning $(and ,)) - $(warning $(and ,) make PYTHON=python2) - $(warning $(and ,)) - $(warning Otherwise, disable Python support entirely:) - $(warning $(and ,)) - $(warning $(and ,) make NO_LIBPYTHON=1) - $(warning $(and ,)) - $(error $(and ,)) - else - LDFLAGS += $(PYTHON_EMBED_LDFLAGS) - EXTLIBS += $(PYTHON_EMBED_LIBADD) - LANG_BINDINGS += $(obj-perf)python/perf.so - $(call detected,CONFIG_LIBPYTHON) - endif And nowadays we either build with PYTHON=python3 or just install the python3 devel packages and perf will build against it. But the leftover feature-libpython-version check made the fast path feature detection to break in all cases except when python2 devel files were installed: $ rpm -qa | grep python.*devel python3-devel-3.9.7-1.fc34.x86_64 $ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; $ make -C tools/perf O=/tmp/build/perf install-bin make: Entering directory '/var/home/acme/git/perf/tools/perf' BUILD: Doing 'make -j32' parallel build HOSTCC /tmp/build/perf/fixdep.o <SNIP> $ cat /tmp/build/perf/feature/test-all.make.output In file included from test-all.c:18: test-libpython-version.c:5:10: error: #error 5 | #error | ^~~~~ $ ldd ~/bin/perf | grep python libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x00007fda6dbcf000) $ As python3 is the norm these days, fix this by just removing the unused feature-libpython-version feature check, making the test-all fast path to work with the common case. With this: $ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; $ make -C tools/perf O=/tmp/build/perf install-bin |& head make: Entering directory '/var/home/acme/git/perf/tools/perf' BUILD: Doing 'make -j32' parallel build HOSTCC /tmp/build/perf/fixdep.o HOSTLD /tmp/build/perf/fixdep-in.o LINK /tmp/build/perf/fixdep Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] $ ldd ~/bin/perf | grep python libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x00007f58800b0000) $ cat /tmp/build/perf/feature/test-all.make.output $ Reviewed-by: James Clark <james.clark@arm.com> Fixes: 66dfdff03d196e51 ("perf tools: Add Python 3 support") Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jaroslav Škarvada <jskarvad@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/lkml/YaYmeeC6CS2b8OSz@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-11-04tools: Bump minimum LLVM C++ std to GNU++14Ian Rogers1-3/+3
LLVM 9 (current release is LLVM 13) moved the minimum C++ version to GNU++14. Bump the version numbers in the feature test and perf build. Reviewed-by: Fangrui Song <maskray@google.com> Signed-off-by: Ian Rogers <irogers@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sedat Dilek <sedat.dilek@gmail.com> Cc: llvm@lists.linux.dev Link: https://lore.kernel.org/r/20211012021321.291635-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-10-26tools build: Drop needless slang include path in test-allJohn Keeping1-1/+1
Commit cbefd24f0aee3a5d ("tools build: Add test to check if slang.h is in /usr/include/slang/") added a proper test to check whether slang.h is in a subdirectory, and commit 1955c8cf5e26b1f7 ("perf tools: Don't hardcode host include path for libslang") removed the include path for test-libslang.bin but missed test-all.bin. Apply the same change to test-all.bin. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Fixes: 1955c8cf5e26 ("perf tools: Don't hardcode host include path for libslang") Signed-off-by: John Keeping <john@metanate.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Nick Terrell <terrelln@fb.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20211025172314.3766032-1-john@metanate.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-28perf tools: Enable libtracefs dynamic linkingIan Rogers1-0/+4
Currently libtracefs isn't used by perf, but there are potential improvements by using it as identified Steven Rostedt's e-mail: https://lore.kernel.org/lkml/20210610154759.1ef958f0@oasis.local.home/ This change is modelled on the dynamic libtraceevent patch by Michael Petlan: https://lore.kernel.org/linux-perf-users/20210428092023.4009-1-mpetlan@redhat.com/ v3. Adds file missed in v1 and v2 spotted by Jiri Olsa. Signed-off-by: Ian Rogers <irogers@google.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com> Cc: linux-trace-devel@vger.kernel.org Link: http://lore.kernel.org/lkml/20210923001024.550263-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-08-09tools: Remove feature-sync-compare-and-swap feature detectionLeo Yan1-4/+0
Since the __sync functions have been removed from perf, it's needless for perf tool to test the feature sync-compare-and-swap. The feature test is not used by any other components, remove it. Signed-off-by: Leo Yan <leo.yan@linaro.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andrii Nakryiko <andriin@fb.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Daniel Díaz <daniel.diaz@linaro.org> Cc: Frank Ch. Eigler <fche@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Mike Leach <mike.leach@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sedat Dilek <sedat.dilek@gmail.com> Cc: Song Liu <songliubraving@fb.com> Cc: Suzuki Poulouse <suzuki.poulose@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: coresight@lists.linaro.org Cc: x86@kernel.org Link: http://lore.kernel.org/lkml/20210809111407.596077-10-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-04-29perf tools: Enable libtraceevent dynamic linkingMichael Petlan1-0/+4
Currently we support only static linking with kernel's libtraceevent (tools/lib/traceevent). This patch adds libtraceevent package detection and support to link perf with it dynamically. The libtraceevent package status is displayed with: $ make VF=1 LIBTRACEEVENT_DYNAMIC=1 ... ... libtraceevent: [ on ] Default behavior remains the same (static linking). Committer testing: $ make LIBTRACEEVENT_DYNAMIC=1 VF=1 O=/tmp/build/perf -C tools/perf install-bin |& grep traceevent Makefile.config:1090: *** Error: No libtraceevent devel library found, please install libtraceevent-devel. Stop. $ Signed-off-by: Michael Petlan <mpetlan@redhat.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> LPU-Reference: 20210428092023.4009-1-mpetlan@redhat.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-01-29tools: Factor Clang, LLC and LLVM utils definitionsSedat Dilek1-2/+2
When dealing with BPF/BTF/pahole and DWARF v5 I wanted to build bpftool. While looking into the source code I found duplicate assignments in misc tools for the LLVM eco system, e.g. clang and llvm-objcopy. Move the Clang, LLC and/or LLVM utils definitions to tools/scripts/Makefile.include file and add missing includes where needed. Honestly, I was inspired by the commit c8a950d0d3b9 ("tools: Factor HOSTCC, HOSTLD, HOSTAR definitions"). I tested with bpftool and perf on Debian/testing AMD64 and LLVM/Clang v11.1.0-rc1. Build instructions: [ make and make-options ] MAKE="make V=1" MAKE_OPTS="HOSTCC=clang HOSTCXX=clang++ HOSTLD=ld.lld CC=clang LD=ld.lld LLVM=1 LLVM_IAS=1" MAKE_OPTS="$MAKE_OPTS PAHOLE=/opt/pahole/bin/pahole" [ clean-up ] $MAKE $MAKE_OPTS -C tools/ clean [ bpftool ] $MAKE $MAKE_OPTS -C tools/bpf/bpftool/ [ perf ] PYTHON=python3 $MAKE $MAKE_OPTS -C tools/perf/ I was careful with respecting the user's wish to override custom compiler, linker, GNU/binutils and/or LLVM utils settings. Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Jiri Olsa <jolsa@redhat.com> # tools/build and tools/perf Link: https://lore.kernel.org/bpf/20210128015117.20515-1-sedat.dilek@gmail.com
2020-12-17tools build: Add missing libcap to test-all.bin targetJiri Olsa1-1/+1
We're missing -lcap in test-all.bin target, so in case it's the only library missing (if more are missing test-all.bin fails anyway), we will falsely claim that we detected it and fail build, like: $ make ... Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... libbfd: [ on ] ... libbfd-buildid: [ on ] ... libcap: [ on ] ... libelf: [ on ] ... libnuma: [ on ] ... numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ... libaio: [ on ] ... libzstd: [ on ] ... disassembler-four-args: [ on ] ... CC builtin-ftrace.o In file included from builtin-ftrace.c:29: util/cap.h:11:10: fatal error: sys/capability.h: No such file or directory 11 | #include <sys/capability.h> | ^~~~~~~~~~~~~~~~~~ compilation terminated. Fixes: 74d5f3d06f707eb5 ("tools build: Add capability-related feature detection") Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Igor Lubashev <ilubashe@akamai.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lore.kernel.org/lkml/20201203230836.3751981-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-10-17Merge tag 'perf-tools-for-v5.10-2020-10-15' of ↵Linus Torvalds1-1/+5
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools updates from Arnaldo Carvalho de Melo: - cgroup improvements for 'perf stat', allowing for compact specification of events and cgroups in the command line. - Support per thread topdown metrics in 'perf stat'. - Support sample-read topdown metric group in 'perf record' - Show start of latency in addition to its start in 'perf sched latency'. - Add min, max to 'perf script' futex-contention output, in addition to avg. - Allow usage of 'perf_event_attr->exclusive' attribute via the new ':e' event modifier. - Add 'snapshot' command to 'perf record --control', using it with Intel PT. - Support FIFO file names as alternative options to 'perf record --control'. - Introduce branch history "streams", to compare 'perf record' runs with 'perf diff' based on branch records and report hot streams. - Support PE executable symbol tables using libbfd, to profile, for instance, wine binaries. - Add filter support for option 'perf ftrace -F/--funcs'. - Allow configuring the 'disassembler_style' 'perf annotate' knob via 'perf config' - Update CascadelakeX and SkylakeX JSON vendor events files. - Add support for parsing perchip/percore JSON vendor events. - Add power9 hv_24x7 core level metric events. - Add L2 prefetch, ITLB instruction fetch hits JSON events for AMD zen1. - Enable Family 19h users by matching Zen2 AMD vendor events. - Use debuginfod in 'perf probe' when required debug files not found locally. - Display negative tid in non-sample events in 'perf script'. - Make GTK2 support opt-in - Add build test with GTK+ - Add missing -lzstd to the fast path feature detection - Add scripts to auto generate 'mmap', 'mremap' string<->id tables for use in 'perf trace'. - Show python test script in verbose mode. - Fix uncore metric expressions - Msan uninitialized use fixes. - Use condition variables in 'perf bench numa' - Autodetect python3 binary in systems without python2. - Support md5 build ids in addition to sha1. - Add build id 'perf test' regression test. - Fix printable strings in python3 scripts. - Fix off by ones in 'perf trace' in arches using libaudit. - Fix JSON event code for events referencing std arch events. - Introduce 'perf test' shell script for Arm CoreSight testing. - Add rdtsc() for Arm64 for used in the PERF_RECORD_TIME_CONV metadata event and in 'perf test tsc'. - 'perf c2c' improvements: Add "RMT Load Hit" metric, "Total Stores", fixes and documentation update. - Fix usage of reloc_sym in 'perf probe' when using both kallsyms and debuginfo files. - Do not print 'Metric Groups:' unnecessarily in 'perf list' - Refcounting fixes in the event parsing code. - Add expand cgroup event 'perf test' entry. - Fix out of bounds CPU map access when handling armv8_pmu events in 'perf stat'. - Add build-id injection 'perf bench' benchmark. - Enter namespace when reading build-id in 'perf inject'. - Do not load map/dso when injecting build-id speeding up the 'perf inject' process. - Add --buildid-all option to avoid processing all samples, just the mmap metadata events. - Add feature test to check if libbfd has buildid support - Add 'perf test' entry for PE binary format support. - Fix typos in power8 PMU vendor events JSON files. - Hide libtraceevent non API functions. * tag 'perf-tools-for-v5.10-2020-10-15' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (113 commits) perf c2c: Update documentation for metrics reorganization perf c2c: Add metrics "RMT Load Hit" perf c2c: Correct LLC load hit metrics perf c2c: Change header for LLC local hit perf c2c: Use more explicit headers for HITM perf c2c: Change header from "LLC Load Hitm" to "Load Hitm" perf c2c: Organize metrics based on memory hierarchy perf c2c: Display "Total Stores" as a standalone metrics perf c2c: Display the total numbers continuously perf bench: Use condition variables in numa. perf jevents: Fix event code for events referencing std arch events perf diff: Support hot streams comparison perf streams: Report hot streams perf streams: Calculate the sum of total streams hits perf streams: Link stream pair perf streams: Compare two streams perf streams: Get the evsel_streams by evsel_idx perf streams: Introduce branch history "streams" perf intel-pt: Improve PT documentation slightly perf tools: Add support for exclusive groups/events ...
2020-09-09tools feature: Add missing -lzstd to the fast path feature detectionArnaldo Carvalho de Melo1-1/+1
We were failing that due to GTK2+ and then for the ZSTD test, which made test-all.c, the fast path feature detection file to fail and thus trigger building all of the feature tests, slowing down the test. Eventually the ZSTD test would be built and would succeed, since it had the needed -lzstd, avoiding: $ cat /tmp/build/perf/feature/test-all.make.output /usr/bin/ld: /tmp/ccRRJQ4u.o: in function `main_test_libzstd': /home/acme/git/perf/tools/build/feature/test-libzstd.c:8: undefined reference to `ZSTD_createCStream' /usr/bin/ld: /home/acme/git/perf/tools/build/feature/test-libzstd.c:9: undefined reference to `ZSTD_freeCStream' collect2: error: ld returned 1 exit status $ Fix it by adding -lzstd to the test-all target. Now I need an entry to 'perf test' to make sure that /tmp/build/perf/feature/test-all.make.output is empty... Fixes: 3b1c5d9659718263 ("tools build: Implement libzstd feature check, LIBZSTD_DIR and NO_LIBZSTD defines") Reviewed-by: Alexei Budankov <alexey.budankov@linux.intel.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Link: http://lore.kernel.org/lkml/20200904202611.GJ3753976@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-04perf tools: Make GTK2 support opt-inArnaldo Carvalho de Melo1-1/+1
This is bitrotting, nobody is stepping up to work on it, and since we treat warnings as errors, feature detection is failing in its main, faster test (tools/build/feature/test-all.c) because of the GTK+2 infobar check. So make this opt-in, at some point ditch this if nobody volunteers to take care of this. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-04tools features: Add feature test to check if libbfd has buildid supportArnaldo Carvalho de Melo1-0/+4
Which is needed by the PE executable support, for instance. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jacek Caban <jacek@codeweavers.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Remi Bernon <rbernon@codeweavers.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-08-19tools: Remove feature-libelf-mmap feature detectionAndrii Nakryiko1-4/+0
It's trivial to handle missing ELF_C_MMAP_READ support in libelf the way that objtool has solved it in ("774bec3fddcc objtool: Add fallback from ELF_C_READ_MMAP to ELF_C_READ"). So instead of having an entire feature detector for that, just do what objtool does for perf and libbpf. And keep their Makefiles a bit simpler. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200819013607.3607269-5-andriin@fb.com
2020-08-14perf build-ids: Fall back to debuginfod query if debuginfo not foundFrank Ch. Eigler1-0/+4
During a perf-record, use the -ldebuginfod API to query a debuginfod server, should the debug data not be found in the usual system locations. If successful, the usual $HOME/.debug dir is populated. Tested with: $ find . . ./ctags-debuginfo-5.8-26.fc31.x86_64.rpm ./usr ./usr/lib ./usr/lib/debug ./usr/lib/debug/.build-id ./usr/lib/debug/.build-id/ca ./usr/lib/debug/.build-id/ca/46f6ae6a0cee57d85abc1d461c49074248908d ./usr/lib/debug/.build-id/ca/46f6ae6a0cee57d85abc1d461c49074248908d.debug ./usr/lib/debug/usr ./usr/lib/debug/usr/bin ./usr/lib/debug/usr/bin/ctags-5.8-26.fc31.x86_64.debug $ debuginfod -F . ... $ rm -rf ~/.debug/ ; mkdir ~/.debug $ perf record make tags BUILD: Doing 'make -j8' parallel build GEN tags [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.107 MB perf.data (1483 samples) ] $ find ~/.debug | grep ctags /home/jolsa/.debug/usr/bin/ctags /home/jolsa/.debug/usr/bin/ctags/ca46f6ae6a0cee57d85abc1d461c49074248908d /home/jolsa/.debug/usr/bin/ctags/ca46f6ae6a0cee57d85abc1d461c49074248908d/elf /home/jolsa/.debug/usr/bin/ctags/ca46f6ae6a0cee57d85abc1d461c49074248908d/probes $ rm -rf ~/.debug/ ; mkdir ~/.debug $ DEBUGINFOD_URLS=http://localhost:8002 perf record make tags BUILD: Doing 'make -j8' parallel build GEN tags [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.108 MB perf.data (1531 samples) ] $ find ~/.debug | grep ctag /home/jolsa/.debug/usr/bin/ctags /home/jolsa/.debug/usr/bin/ctags/ca46f6ae6a0cee57d85abc1d461c49074248908d /home/jolsa/.debug/usr/bin/ctags/ca46f6ae6a0cee57d85abc1d461c49074248908d/debug /home/jolsa/.debug/usr/bin/ctags/ca46f6ae6a0cee57d85abc1d461c49074248908d/elf /home/jolsa/.debug/usr/bin/ctags/ca46f6ae6a0cee57d85abc1d461c49074248908d/probes Note the 'debug' file is created in the last run. Note that currently the debuginfo data are downloaded only on record path, we still need add this support to perf build-id/report.. and test ;-) Tested-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Frank Ch. Eigler <fche@redhat.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-08-06Mgerge remote-tracking branch 'torvalds/master' into perf/coreArnaldo Carvalho de Melo1-2/+2
To sync headers, for instance, in this case tools/perf was ahead of upstream till Linus merged tip/perf/core to get the PERF_RECORD_TEXT_POKE changes: Warning: Kernel ABI header at 'tools/include/uapi/linux/perf_event.h' differs from latest version at 'include/uapi/linux/perf_event.h' diff -u tools/include/uapi/linux/perf_event.h include/uapi/linux/perf_event.h Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-07-31tools build feature: Use CC and CXX from parentThomas Hebb1-2/+0
commit c8c188679ccf ("tools build: Use the same CC for feature detection and actual build") changed these assignments from unconditional (:=) to conditional (?=) so that they wouldn't clobber values from the environment. However, conditional assignment does not work properly for variables that Make implicitly sets, among which are CC and CXX. To quote tools/scripts/Makefile.include, which handles this properly: # Makefiles suck: This macro sets a default value of $(2) for the # variable named by $(1), unless the variable has been set by # environment or command line. This is necessary for CC and AR # because make sets default values, so the simpler ?= approach # won't work as expected. In other words, the conditional assignments will not run even if the variables are not overridden in the environment; Make will set CC to "cc" and CXX to "g++" when it starts[1], meaning the variables are not empty by the time the conditional assignments are evaluated. This breaks cross-compilation when CROSS_COMPILE is set but CC isn't, since "cc" gets used for feature detection instead of the cross compiler (and likewise for CXX). To fix the issue, just pass down the values of CC and CXX computed by the parent Makefile, which gets included by the Makefile that actually builds whatever we're detecting features for and so is guaranteed to have good values. This is a better solution anyway, since it means we aren't trying to replicate the logic of the parent build system and so don't risk it getting out of sync. Leave PKG_CONFIG alone, since 1) there's no common logic to compute it in Makefile.include, and 2) it's not an implicit variable, so conditional assignment works properly. [1] https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html Fixes: c8c188679ccf ("tools build: Use the same CC for feature detection and actual build") Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: David Carrillo-Cisneros <davidcc@google.com> Cc: Ian Rogers <irogers@google.com> Cc: Igor Lubashev <ilubashe@akamai.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Quentin Monnet <quentin@isovalent.com> Cc: Song Liu <songliubraving@fb.com> Cc: Stephane Eranian <eranian@google.com> Cc: thomas hebb <tommyhebb@gmail.com> Link: http://lore.kernel.org/lkml/0a6e69d1736b0fa231a648f50b0cce5d8a6734ef.1595822871.git.tommyhebb@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-06-23tools/bpftool: Generalize BPF skeleton support and generate vmlinux.hAndrii Nakryiko1-2/+2
Adapt Makefile to support BPF skeleton generation beyond single profiler.bpf.c case. Also add vmlinux.h generation and switch profiler.bpf.c to use it. clang-bpf-global-var feature is extended and renamed to clang-bpf-co-re to check for support of preserve_access_index attribute, which, together with BTF for global variables, is the minimum requirement for modern BPF programs. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20200619231703.738941-7-andriin@fb.com
2020-05-29perf build: Remove libaudit from the default feature checksArnaldo Carvalho de Melo1-1/+1
Ingo reported that the libaudit was always appearing as OFF: Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ OFF ] And everything seemed to work, i.e. we were checking for a feature that we don't use, causing confusion for people building perf, so work to remove that nuisance while making sure that it works when an arch doesn't provide the alternative method to generate the syscall id/name conversion tables. Longer explanation of the new modus operandi: $ make -C tools/perf O=/tmp/build/perf NO_SYSCALL_TABLE=1 <SNIP> Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libbfd: [ on ] ... libcap: [ on ] ... libelf: [ on ] ... libnuma: [ on ] ... numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ... libaio: [ on ] ... libzstd: [ on ] ... disassembler-four-args: [ on ] Makefile.config:665: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev GEN /tmp/build/perf/common-cmds.h MKDIR /tmp/build/perf/fd/ MKDIR /tmp/build/perf/fs/ <SNIP> $ The libaudit test is forced and it fails when audit-libs-devel isn't available: $ cat /tmp/build/perf/feature/test-libaudit.make.output test-libaudit.c:2:10: fatal error: libaudit.h: No such file or directory 2 | #include <libaudit.h> | ^~~~~~~~~~~~ compilation terminated. $ If we install audit-libs-devel and rebuild it continues not to be shown as OFF in the main auto-detection summary, but again gets tested and this time: $ rpm -q audit-libs-devel audit-libs-devel-3.0-0.15.20191104git1c2f876.fc31.x86_64 $ The make output for the feature detection comes clean: $ cat /tmp/build/perf/feature/test-libaudit.make.output And the feature detection binary is successfully built and is dynamicly linked with libaudit: $ ldd /tmp/build/perf/feature/test-libaudit.bin | grep audit libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f5bf5177000) $ As well as the resulting perf binary: $ ldd /tmp/build/perf/perf | grep audit libaudit.so.1 => /lib64/libaudit.so.1 (0x00007fad511c7000) $ And 'perf trace' works using the libaudit method: $ sudo /tmp/build/perf/perf trace -e nanosleep sleep 1 0.000 (1000.067 ms): sleep/281872 nanosleep(rqtp: 0x7ffedbbe69d0) = 0 $ If we leave audit-libs-devel installed but don't disable the use of the best method, the one using SYSCALL_TABLE, the default for architectures that provide the script to build the syscall id/name mapping using the .tbl files copied from the kernel sources, we get: $ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf $ make -C tools/perf O=/tmp/build/perf Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libbfd: [ on ] ... libcap: [ on ] ... libelf: [ on ] ... libnuma: [ on ] ... numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ... libaio: [ on ] ... libzstd: [ on ] ... disassembler-four-args: [ on ] GEN /tmp/build/perf/common-cmds.h <SNIP> $ Again, no mention of libaudit being on or OFF and: $ cat /tmp/build/perf/feature/test-libaudit.make.output cat: /tmp/build/perf/feature/test-libaudit.make.output: No such file or directory $ We didn't even bother checking for its availability, slightly speeding up the build process and: $ ldd /tmp/build/perf/perf | grep libaudit $ We don't link with it, also: $ sudo /tmp/build/perf/perf trace -e nanosleep sleep 1 0.000 (1000.053 ms): sleep/299125 nanosleep(rqtp: 0x7ffc24611b50) = 0 $ And globs become available: $ sudo /tmp/build/perf/perf trace -e *sleep sleep 1 0.000 (1000.072 ms): sleep/299136 nanosleep(rqtp: 0x7ffe7a3c4ff0) = 0 $ Reported-by: Ingo Molnar <mingo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-05-05tools feature: Add support for detecting libpfm4Stephane Eranian1-1/+5
libpfm4 provides an alternate command line encoding of perf events. Signed-off-by: Stephane Eranian <eranian@google.com> Reviewed-by: Ian Rogers <irogers@google.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andrii Nakryiko <andriin@fb.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Igor Lubashev <ilubashe@akamai.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiwei Sun <jiwei.sun@windriver.com> Cc: John Garry <john.garry@huawei.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yonghong Song <yhs@fb.com> Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Cc: yuzhoujian <yuzhoujian@didichuxing.com> Link: http://lore.kernel.org/lkml/20200429231443.207201-3-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-04-05Merge tag 'perf-urgent-2020-04-05' of ↵Linus Torvalds1-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull more perf updates from Thomas Gleixner: "Perf updates all over the place: core: - Support for cgroup tracking in samples to allow cgroup based analysis tools: - Support for cgroup analysis - Commandline option and hotkey for perf top to change the sort order - A set of fixes all over the place - Various build system related improvements - Updates of the X86 pmu event JSON data - Documentation updates" * tag 'perf-urgent-2020-04-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (55 commits) perf python: Fix clang detection to strip out options passed in $CC perf tools: Support Python 3.8+ in Makefile perf script: Fix invalid read of directory entry after closedir() perf script report: Fix SEGFAULT when using DWARF mode perf script: add -S/--symbols documentation perf pmu-events x86: Use CPU_CLK_UNHALTED.THREAD in Kernel_Utilization metric perf events parser: Add missing Intel CPU events to parser perf script: Allow --symbol to accept hexadecimal addresses perf report/top TUI: Fix title line formatting perf top: Support hotkey to change sort order perf top: Support --group-sort-idx to change the sort order perf symbols: Fix arm64 gap between kernel start and module end perf build-test: Honour JOBS to override detection of number of cores perf script: Add --show-cgroup-events option perf top: Add --all-cgroups option perf record: Add --all-cgroups option perf record: Support synthesizing cgroup events perf report: Add 'cgroup' sort key perf cgroup: Maintain cgroup hierarchy perf tools: Basic support for CGROUP event ...
2020-04-03perf tools: Add file-handle feature testNamhyung Kim1-1/+5
The file handle (FHANDLE) support is configurable so some systems might not have it. So add a config feature item to check it on build time so that we don't add the cgroup tracking feature based on that. Committer notes: Had to make the test use the same construct as its later use in synthetic-events.c, in the next patch in this series. i.e. make it be: struct { struct file_handle fh; uint64_t cgroup_id; } handle; To cope with: CC /tmp/build/perf/util/cloexec.o util/synthetic-events.c:428:22: error: field 'fh' with CC /tmp/build/perf/util/call-path.o variable sized type 'struct file_handle' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end] struct file_handle fh; ^ 1 error generated. Deal with this at some point, i.e. investigate if the right thing is to remove that -Wgnu-variable-sized-type-not-at-end from our CFLAGS, for now do the test the same way as it is used looks more sensible. Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200402015249.3800462-1-namhyung@kernel.org [ split from a larger patch, removed blank line at EOF ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-13bpftool: Only build bpftool-prog-profile if supported by clangSong Liu1-1/+8
bpftool-prog-profile requires clang to generate BTF for global variables. When compared with older clang, skip this command. This is achieved by adding a new feature, clang-bpf-global-var, to tools/build/feature. Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20200312182332.3953408-2-songliubraving@fb.com
2020-01-14perf/ui/gtk: Fix gtk2 buildJiri Olsa1-1/+1
Ravi Bangoria reported an issue when doing the gtk2 feature detection on Fedora 31, where some types got deprecated: /usr/include/gtk-2.0/gtk/gtktypeutils.h:236:1: error: ‘GTypeDebugFlags’ is deprecated [-Werror=deprecated-declarations] 236 | void gtk_type_init (GTypeDebugFlags debug_flags); Fix this for perf by allowing the compile to pass with deprecated symbols via the -Wno-deprecated-declarations compiler directive. Reported-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jelle van der Waa <jelle@vdwaa.nl> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200113104358.123511-2-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-11-26perf tools: Allow to link with libbpf dynamicalyJiri Olsa1-0/+4
Currently we support only static linking with kernel's libbpf (tools/lib/bpf). This patch adds libbpf package detection and support to link perf with it dynamically. The libbpf package status is displayed with: $ make VF=1 Auto-detecting system features: ... ... libbpf: [ on ] It's not checked by default, because it's quite new. Once it's on most distros we can switch it on. For the same reason it's not added to the test-all check. Perf does not need advanced version of libbpf, so we can check just for the base bpf_object__open function. Adding new compile variable to detect libbpf package and link bpf dynamically: $ make LIBBPF_DYNAMIC=1 ... LINK perf $ ldd perf | grep bpf libbpf.so.0 => /lib64/libbpf.so.0 (0x00007f46818bc000) If libbpf is not installed, build stops with: Makefile.config:486: *** Error: No libbpf devel library found,\ please install libbpf-devel. Stop. Committer testing: $ make LIBBPF_DYNAMIC=1 -C tools/perf O=/tmp/build/perf make: Entering directory '/home/acme/git/perf/tools/perf' BUILD: Doing 'make -j8' parallel build Makefile.config:493: *** Error: No libbpf devel library found, please install libbpf-devel. Stop. make[1]: *** [Makefile.perf:225: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 make: Leaving directory '/home/acme/git/perf/tools/perf' $ Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Toke Høiland-Jørgensen <toke@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> Cc: Andrii Nakryiko <andriin@fb.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Jesper Dangaard Brouer <brouer@redhat.com> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <songliubraving@fb.com> Cc: Yonghong Song <yhs@fb.com> Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20191126121253.28253-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-08-12tools build: Add capability-related feature detectionIgor Lubashev1-0/+4
Add utilities to help checking capabilities of the running procss. Make perf link with libcap, if it is available. If no libcap-dev[el], assume no capabilities. Committer testing: $ make O=/tmp/build/perf -C tools/perf install-bin make: Entering directory '/home/acme/git/perf/tools/perf' BUILD: Doing 'make -j8' parallel build Auto-detecting system features: <SNIP> ... libbfd: [ on ] ... libcap: [ OFF ] ... libelf: [ on ] <SNIP> Makefile.config:833: No libcap found, disables capability support, please install libcap-devel/libcap-dev <SNIP> $ grep libcap /tmp/build/perf/FEATURE-DUMP feature-libcap=0 $ cat /tmp/build/perf/feature/test-libcap.make.output test-libcap.c:2:10: fatal error: sys/capability.h: No such file or directory 2 | #include <sys/capability.h> | ^~~~~~~~~~~~~~~~~~ compilation terminated. $ Now install libcap-devel and try again: $ make O=/tmp/build/perf -C tools/perf install-bin make: Entering directory '/home/acme/git/perf/tools/perf' BUILD: Doing 'make -j8' parallel build Warning: Kernel ABI header at 'tools/include/linux/bits.h' differs from latest version at 'include/linux/bits.h' diff -u tools/include/linux/bits.h include/linux/bits.h Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' differs from latest version at 'arch/x86/include/asm/cpufeatures.h' diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h Auto-detecting system features: <SNIP> ... libbfd: [ on ] ... libcap: [ on ] ... libelf: [ on ] <SNIP>> CC /tmp/build/perf/jvmti/libjvmti.o <SNIP>> $ grep libcap /tmp/build/perf/FEATURE-DUMP feature-libcap=1 $ cat /tmp/build/perf/feature/test-libcap.make.output $ ldd /tmp/build/perf/feature/test-libcap.make.bin ldd: /tmp/build/perf/feature/test-libcap.make.bin: No such file or directory $ ldd /tmp/build/perf/feature/test-libcap.bin linux-vdso.so.1 (0x00007ffc35bfe000) libcap.so.2 => /lib64/libcap.so.2 (0x00007ff9c62ff000) libc.so.6 => /lib64/libc.so.6 (0x00007ff9c6139000) /lib64/ld-linux-x86-64.so.2 (0x00007ff9c6326000) $ Signed-off-by: Igor Lubashev <ilubashe@akamai.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: James Morris <jmorris@namei.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suzuki Poulouse <suzuki.poulose@arm.com> [ split from a larger patch ] Link: http://lkml.kernel.org/r/8a1e76cf5c7c9796d0d4d240fbaa85305298aafa.1565188228.git.ilubashe@akamai.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-06-18tools build: Add test to check if slang.h is in /usr/include/slang/Arnaldo Carvalho de Melo1-0/+4
A few odd old distros (rhel5, 6, yeah, lots of those out in use, in many cases we want to use upstream perf on it) have the slang header files in /usr/include/slang/, so add a test that will be performed only when test-all.c (the one with the most common sane settings) fails, either because we're in one of these odd distros with slang/slang.h or because something else failed (say libelf is not present). So for the common case nothing changes, no additional test is performed. Next step is to check in perf the result of these tests. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Fixes: 1955c8cf5e26 ("perf tools: Don't hardcode host include path for libslang") Link: https://lkml.kernel.org/n/tip-2sy7hbwkx68jr6n97qxgg0c6@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-06-17perf tools: Don't hardcode host include path for libslangFlorian Fainelli1-1/+1
Hardcoding /usr/include/slang is fundamentally incompatible with cross compilation and will lead to the inability for a cross-compiled environment to properly detect whether slang is available or not. If /usr/include/slang is necessary that is a distribution specific knowledge that could be solved with either a standard pkg-config .pc file (which slang has) or simply overriding CFLAGS accordingly, but the default perf Makefile should be clean of all of that. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: Jakub Kicinski <jakub.kicinski@netronome.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Quentin Monnet <quentin.monnet@netronome.com> Cc: Stanislav Fomichev <sdf@google.com> Fixes: ef7b93a11904 ("perf report: Librarize the annotation code and use it in the newt browser") Link: http://lkml.kernel.org/r/20190614183949.5588-1-f.fainelli@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-06-17tools build: Check if gettid() is available before providing helperArnaldo Carvalho de Melo1-0/+4
Laura reported that the perf build failed in fedora when we got a glibc that provides gettid(), which I reproduced using fedora rawhide with the glibc-devel-2.29.9000-26.fc31.x86_64 package. Add a feature check to avoid providing a gettid() helper in such systems. On a fedora rawhide system with this patch applied we now get: [root@7a5f55352234 perf]# grep gettid /tmp/build/perf/FEATURE-DUMP feature-gettid=1 [root@7a5f55352234 perf]# cat /tmp/build/perf/feature/test-gettid.make.output [root@7a5f55352234 perf]# ldd /tmp/build/perf/feature/test-gettid.bin linux-vdso.so.1 (0x00007ffc6b1f6000) libc.so.6 => /lib64/libc.so.6 (0x00007f04e0a74000) /lib64/ld-linux-x86-64.so.2 (0x00007f04e0c47000) [root@7a5f55352234 perf]# nm /tmp/build/perf/feature/test-gettid.bin | grep -w gettid U gettid@@GLIBC_2.30 [root@7a5f55352234 perf]# While on a fedora:29 system: [acme@quaco perf]$ grep gettid /tmp/build/perf/FEATURE-DUMP feature-gettid=0 [acme@quaco perf]$ cat /tmp/build/perf/feature/test-gettid.make.output test-gettid.c: In function ‘main’: test-gettid.c:8:9: error: implicit declaration of function ‘gettid’; did you mean ‘getgid’? [-Werror=implicit-function-declaration] return gettid(); ^~~~~~ getgid cc1: all warnings being treated as errors [acme@quaco perf]$ Reported-by: Laura Abbott <labbott@redhat.com> Tested-by: Laura Abbott <labbott@redhat.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Florian Weimer <fweimer@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Link: https://lkml.kernel.org/n/tip-yfy3ch53agmklwu9o7rlgf9c@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-04-01tools build: Implement libzstd feature check, LIBZSTD_DIR and NO_LIBZSTD definesAlexey Budankov1-1/+5
Implement libzstd feature check, NO_LIBZSTD and LIBZSTD_DIR defines to override Zstd library sources or disable the feature from the command line: $ make -C tools/perf LIBZSTD_DIR=/path/to/zstd/sources/ clean all $ make -C tools/perf NO_LIBZSTD=1 clean all Auto detection feature status is reported just before compilation starts. If your system has some version of the zstd library preinstalled then the build system finds and uses it during the build. If you still prefer to compile with some other version of zstd library you have capability to refer the compilation to that version using LIBZSTD_DIR define. Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com> Reviewed-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/9b4cd8b0-10a3-1f1e-8d6b-5922a7ca216b@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-12-21perf build: Don't unconditionally link the libbfd feature test to -liberty ↵Stanislav Fomichev1-5/+5
and -lz 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 2cf9040714f3 ("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 280e7c48c3b8 ("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>
2018-12-17tools build feature: Check if libaio is availableAlexey Budankov1-1/+5
This will be used by 'perf record' to speed up reading the perf ring buffer. Committer testing: $ make -C tools/perf O=/tmp/build/perf 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: [ OFF ] ... libaudit: [ OFF ] ... libbfd: [ OFF ] ... libelf: [ on ] ... libnuma: [ OFF ] ... numa_num_possible_cpus: [ OFF ] ... libperl: [ OFF ] ... libpython: [ OFF ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ... libaio: [ on ] $ ls -la /tmp/build/perf/feature/test-libaio.* -rwxrwxr-x. 1 acme acme 18296 Nov 26 08:49 /tmp/build/perf/feature/test-libaio.bin -rw-rw-r--. 1 acme acme 1165 Nov 26 08:49 /tmp/build/perf/feature/test-libaio.d -rw-rw-r--. 1 acme acme 0 Nov 26 08:49 /tmp/build/perf/feature/test-libaio.make.output $ $ grep -i aio /tmp/build/perf/FEATURE-DUMP feature-libaio=1 $ Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Reviewed-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/5fcda10c-6c63-68df-383a-c6d9e5d1f918@linux.intel.com [ split from a larger patch ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-11-22perf jvmti: Separate jvmti cmlr checkJiri Olsa1-0/+4
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>
2018-11-22tools build feature: Check if eventfd() is availableArnaldo Carvalho de Melo1-0/+4
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>
2018-11-19tools build feature: Check if get_current_dir_name() is availableArnaldo Carvalho de Melo1-0/+4
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>
2018-07-11tools: bpf: make use of reallocarrayJakub Kicinski1-0/+4
reallocarray() is a safer variant of realloc which checks for multiplication overflow in case of array allocation. Since it's not available in Glibc < 2.26 import kernel's overflow.h and add a static inline implementation when needed. Use feature detection to probe for existence of reallocarray. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-08perf build: Force llvm/clang test compile output to .make.outputJiri Olsa1-3/+6
So we can see the output of feature compile in following files: tools/build/feature/test-llvm.make.output tools/build/feature/test-llvm-version.make.output tools/build/feature/test-clang.make.output Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@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/20180307155020.32613-20-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-03-08perf build: Add llvm/clang make targets to FILESJiri Olsa1-1/+4
So they can follow the OUTPUT variable setup as the rest of the features. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@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/20180307155020.32613-19-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-02-01Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-nextLinus Torvalds1-0/+4
Pull networking updates from David Miller: 1) Significantly shrink the core networking routing structures. Result of http://vger.kernel.org/~davem/seoul2017_netdev_keynote.pdf 2) Add netdevsim driver for testing various offloads, from Jakub Kicinski. 3) Support cross-chip FDB operations in DSA, from Vivien Didelot. 4) Add a 2nd listener hash table for TCP, similar to what was done for UDP. From Martin KaFai Lau. 5) Add eBPF based queue selection to tun, from Jason Wang. 6) Lockless qdisc support, from John Fastabend. 7) SCTP stream interleave support, from Xin Long. 8) Smoother TCP receive autotuning, from Eric Dumazet. 9) Lots of erspan tunneling enhancements, from William Tu. 10) Add true function call support to BPF, from Alexei Starovoitov. 11) Add explicit support for GRO HW offloading, from Michael Chan. 12) Support extack generation in more netlink subsystems. From Alexander Aring, Quentin Monnet, and Jakub Kicinski. 13) Add 1000BaseX, flow control, and EEE support to mvneta driver. From Russell King. 14) Add flow table abstraction to netfilter, from Pablo Neira Ayuso. 15) Many improvements and simplifications to the NFP driver bpf JIT, from Jakub Kicinski. 16) Support for ipv6 non-equal cost multipath routing, from Ido Schimmel. 17) Add resource abstration to devlink, from Arkadi Sharshevsky. 18) Packet scheduler classifier shared filter block support, from Jiri Pirko. 19) Avoid locking in act_csum, from Davide Caratti. 20) devinet_ioctl() simplifications from Al viro. 21) More TCP bpf improvements from Lawrence Brakmo. 22) Add support for onlink ipv6 route flag, similar to ipv4, from David Ahern. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1925 commits) tls: Add support for encryption using async offload accelerator ip6mr: fix stale iterator net/sched: kconfig: Remove blank help texts openvswitch: meter: Use 64-bit arithmetic instead of 32-bit tcp_nv: fix potential integer overflow in tcpnv_acked r8169: fix RTL8168EP take too long to complete driver initialization. qmi_wwan: Add support for Quectel EP06 rtnetlink: enable IFLA_IF_NETNSID for RTM_NEWLINK ipmr: Fix ptrdiff_t print formatting ibmvnic: Wait for device response when changing MAC qlcnic: fix deadlock bug tcp: release sk_frag.page in tcp_disconnect ipv4: Get the address of interface correctly. net_sched: gen_estimator: fix lockdep splat net: macb: Handle HRESP error net/mlx5e: IPoIB, Fix copy-paste bug in flow steering refactoring ipv6: addrconf: break critical section in addrconf_verify_rtnl() ipv6: change route cache aging logic i40e/i40evf: Update DESC_NEEDED value to reflect larger value bnxt_en: cleanup DIM work on device shutdown ...
2018-01-25perf tools: Integrating the CoreSight decoding libraryMathieu Poirier1-1/+6
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>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-25 16:34:26 +0300