License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2021-01-28 09:50:58 +08:00
|
|
|
include ../../scripts/Makefile.include
|
|
|
|
|
|
2016-12-05 04:42:53 +08:00
|
|
|
FILES= \
|
|
|
|
|
test-all.bin \
|
|
|
|
|
test-backtrace.bin \
|
|
|
|
|
test-bionic.bin \
|
|
|
|
|
test-dwarf.bin \
|
|
|
|
|
test-dwarf_getlocations.bin \
|
2018-11-22 04:42:00 +08:00
|
|
|
test-eventfd.bin \
|
2016-12-05 04:42:53 +08:00
|
|
|
test-fortify-source.bin \
|
2018-11-20 03:56:22 +08:00
|
|
|
test-get_current_dir_name.bin \
|
2016-12-05 04:42:53 +08:00
|
|
|
test-glibc.bin \
|
|
|
|
|
test-gtk2.bin \
|
|
|
|
|
test-gtk2-infobar.bin \
|
|
|
|
|
test-hello.bin \
|
|
|
|
|
test-libaudit.bin \
|
|
|
|
|
test-libbfd.bin \
|
2020-09-04 00:44:39 +08:00
|
|
|
test-libbfd-buildid.bin \
|
2017-12-28 03:16:29 +08:00
|
|
|
test-disassembler-four-args.bin \
|
2022-08-01 09:38:27 +08:00
|
|
|
test-disassembler-init-styled.bin \
|
2018-07-11 05:43:05 +08:00
|
|
|
test-reallocarray.bin \
|
2018-11-16 08:32:01 +08:00
|
|
|
test-libbfd-liberty.bin \
|
|
|
|
|
test-libbfd-liberty-z.bin \
|
2016-12-05 04:42:53 +08:00
|
|
|
test-cplus-demangle.bin \
|
2023-03-11 14:57:48 +08:00
|
|
|
test-cxa-demangle.bin \
|
2019-08-07 22:44:14 +08:00
|
|
|
test-libcap.bin \
|
2016-12-05 04:42:53 +08:00
|
|
|
test-libelf.bin \
|
|
|
|
|
test-libelf-getphdrnum.bin \
|
|
|
|
|
test-libelf-gelf_getnote.bin \
|
|
|
|
|
test-libelf-getshdrstrndx.bin \
|
2020-08-13 16:22:04 +08:00
|
|
|
test-libdebuginfod.bin \
|
2016-12-05 04:42:53 +08:00
|
|
|
test-libnuma.bin \
|
|
|
|
|
test-numa_num_possible_cpus.bin \
|
|
|
|
|
test-libperl.bin \
|
|
|
|
|
test-libpython.bin \
|
|
|
|
|
test-libslang.bin \
|
2019-06-19 04:43:35 +08:00
|
|
|
test-libslang-include-subdir.bin \
|
2021-04-28 17:20:23 +08:00
|
|
|
test-libtraceevent.bin \
|
2021-09-23 08:10:21 +08:00
|
|
|
test-libtracefs.bin \
|
2016-12-05 04:42:53 +08:00
|
|
|
test-libcrypto.bin \
|
|
|
|
|
test-libunwind.bin \
|
|
|
|
|
test-libunwind-debug-frame.bin \
|
|
|
|
|
test-libunwind-x86.bin \
|
|
|
|
|
test-libunwind-x86_64.bin \
|
|
|
|
|
test-libunwind-arm.bin \
|
|
|
|
|
test-libunwind-aarch64.bin \
|
|
|
|
|
test-libunwind-debug-frame-arm.bin \
|
|
|
|
|
test-libunwind-debug-frame-aarch64.bin \
|
|
|
|
|
test-pthread-attr-setaffinity-np.bin \
|
2017-12-05 21:14:42 +08:00
|
|
|
test-pthread-barrier.bin \
|
2016-12-05 04:42:53 +08:00
|
|
|
test-stackprotector-all.bin \
|
|
|
|
|
test-timerfd.bin \
|
|
|
|
|
test-libdw-dwarf-unwind.bin \
|
|
|
|
|
test-libbabeltrace.bin \
|
|
|
|
|
test-compile-32.bin \
|
|
|
|
|
test-compile-x32.bin \
|
|
|
|
|
test-zlib.bin \
|
|
|
|
|
test-lzma.bin \
|
|
|
|
|
test-bpf.bin \
|
2019-11-26 20:12:53 +08:00
|
|
|
test-libbpf.bin \
|
2016-12-05 04:42:53 +08:00
|
|
|
test-get_cpuid.bin \
|
|
|
|
|
test-sdt.bin \
|
|
|
|
|
test-cxx.bin \
|
2019-06-13 23:04:19 +08:00
|
|
|
test-gettid.bin \
|
2017-03-02 23:55:49 +08:00
|
|
|
test-jvmti.bin \
|
2018-11-21 23:43:41 +08:00
|
|
|
test-jvmti-cmlr.bin \
|
2023-04-04 22:05:57 +08:00
|
|
|
test-scandirat.bin \
|
2017-07-19 04:15:29 +08:00
|
|
|
test-sched_getcpu.bin \
|
2018-01-18 01:52:10 +08:00
|
|
|
test-setns.bin \
|
2018-03-07 23:50:19 +08:00
|
|
|
test-libopencsd.bin \
|
|
|
|
|
test-clang.bin \
|
|
|
|
|
test-llvm.bin \
|
2018-11-06 17:03:35 +08:00
|
|
|
test-llvm-version.bin \
|
2019-03-19 01:39:49 +08:00
|
|
|
test-libaio.bin \
|
2020-03-13 02:23:30 +08:00
|
|
|
test-libzstd.bin \
|
2020-06-20 07:17:00 +08:00
|
|
|
test-clang-bpf-co-re.bin \
|
2020-04-30 07:14:41 +08:00
|
|
|
test-file-handle.bin \
|
|
|
|
|
test-libpfm4.bin
|
2013-09-30 16:08:24 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
FILES := $(addprefix $(OUTPUT),$(FILES))
|
|
|
|
|
|
2017-04-12 14:49:14 +08:00
|
|
|
PKG_CONFIG ?= $(CROSS_COMPILE)pkg-config
|
2013-09-30 19:51:28 +08:00
|
|
|
|
2013-09-30 16:08:24 +08:00
|
|
|
all: $(FILES)
|
|
|
|
|
|
2017-04-12 14:49:14 +08:00
|
|
|
__BUILD = $(CC) $(CFLAGS) -MD -Wall -Werror -o $@ $(patsubst %.bin,%.c,$(@F)) $(LDFLAGS)
|
2015-12-15 23:39:32 +08:00
|
|
|
BUILD = $(__BUILD) > $(@:.bin=.make.output) 2>&1
|
tools, build: Retry detection of bfd-related features
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-07-20 01:05:52 +08:00
|
|
|
BUILD_BFD = $(BUILD) -DPACKAGE='"perf"' -lbfd -ldl
|
|
|
|
|
BUILD_ALL = $(BUILD) -fstack-protector-all -O2 -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lelf -lslang $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl -lz -llzma -lzstd -lcap
|
2013-09-30 16:08:24 +08:00
|
|
|
|
2017-04-12 14:49:14 +08:00
|
|
|
__BUILDXX = $(CXX) $(CXXFLAGS) -MD -Wall -Werror -o $@ $(patsubst %.bin,%.cpp,$(@F)) $(LDFLAGS)
|
2016-09-26 15:26:56 +08:00
|
|
|
BUILDXX = $(__BUILDXX) > $(@:.bin=.make.output) 2>&1
|
|
|
|
|
|
2013-09-30 16:08:24 +08:00
|
|
|
###############################
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-all.bin:
|
tools, build: Retry detection of bfd-related features
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-07-20 01:05:52 +08:00
|
|
|
$(BUILD_ALL) || $(BUILD_ALL) -lopcodes -liberty
|
2013-10-01 20:14:31 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-hello.bin:
|
2013-09-30 16:08:24 +08:00
|
|
|
$(BUILD)
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-pthread-attr-setaffinity-np.bin:
|
2015-02-28 17:16:27 +08:00
|
|
|
$(BUILD) -D_GNU_SOURCE -lpthread
|
2015-01-13 21:43:24 +08:00
|
|
|
|
2017-12-05 21:14:42 +08:00
|
|
|
$(OUTPUT)test-pthread-barrier.bin:
|
|
|
|
|
$(BUILD) -lpthread
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-stackprotector-all.bin:
|
2015-02-28 17:16:27 +08:00
|
|
|
$(BUILD) -fstack-protector-all
|
2013-09-30 19:48:44 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-fortify-source.bin:
|
2015-02-28 17:16:27 +08:00
|
|
|
$(BUILD) -O2 -D_FORTIFY_SOURCE=2
|
2013-10-07 15:38:28 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-bionic.bin:
|
2013-09-30 20:11:46 +08:00
|
|
|
$(BUILD)
|
|
|
|
|
|
2019-08-07 22:44:14 +08:00
|
|
|
$(OUTPUT)test-libcap.bin:
|
|
|
|
|
$(BUILD) -lcap
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libelf.bin:
|
2013-09-30 20:20:25 +08:00
|
|
|
$(BUILD) -lelf
|
|
|
|
|
|
2018-11-22 04:42:00 +08:00
|
|
|
$(OUTPUT)test-eventfd.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2018-11-20 03:56:22 +08:00
|
|
|
$(OUTPUT)test-get_current_dir_name.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-glibc.bin:
|
2013-10-07 16:34:20 +08:00
|
|
|
$(BUILD)
|
|
|
|
|
|
2023-04-04 22:05:57 +08:00
|
|
|
$(OUTPUT)test-scandirat.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2017-03-02 23:55:49 +08:00
|
|
|
$(OUTPUT)test-sched_getcpu.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2017-07-19 04:15:29 +08:00
|
|
|
$(OUTPUT)test-setns.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2018-01-18 01:52:10 +08:00
|
|
|
$(OUTPUT)test-libopencsd.bin:
|
|
|
|
|
$(BUILD) # -lopencsd_c_api -lopencsd provided by
|
|
|
|
|
# $(FEATURE_CHECK_LDFLAGS-libopencsd)
|
|
|
|
|
|
2015-08-13 06:48:37 +08:00
|
|
|
DWARFLIBS := -ldw
|
|
|
|
|
ifeq ($(findstring -static,${LDFLAGS}),-static)
|
|
|
|
|
DWARFLIBS += -lelf -lebl -lz -llzma -lbz2
|
|
|
|
|
endif
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-dwarf.bin:
|
2015-08-13 06:48:37 +08:00
|
|
|
$(BUILD) $(DWARFLIBS)
|
2013-10-07 16:35:39 +08:00
|
|
|
|
2016-04-05 22:33:41 +08:00
|
|
|
$(OUTPUT)test-dwarf_getlocations.bin:
|
|
|
|
|
$(BUILD) $(DWARFLIBS)
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libelf-getphdrnum.bin:
|
2013-09-30 20:35:27 +08:00
|
|
|
$(BUILD) -lelf
|
|
|
|
|
|
2016-07-12 23:19:09 +08:00
|
|
|
$(OUTPUT)test-libelf-gelf_getnote.bin:
|
|
|
|
|
$(BUILD) -lelf
|
|
|
|
|
|
2016-07-05 06:35:47 +08:00
|
|
|
$(OUTPUT)test-libelf-getshdrstrndx.bin:
|
|
|
|
|
$(BUILD) -lelf
|
|
|
|
|
|
2020-08-13 16:22:04 +08:00
|
|
|
$(OUTPUT)test-libdebuginfod.bin:
|
|
|
|
|
$(BUILD) -ldebuginfod
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libnuma.bin:
|
2013-09-30 19:37:10 +08:00
|
|
|
$(BUILD) -lnuma
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-numa_num_possible_cpus.bin:
|
2015-09-17 23:20:28 +08:00
|
|
|
$(BUILD) -lnuma
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libunwind.bin:
|
2013-12-10 20:24:04 +08:00
|
|
|
$(BUILD) -lelf
|
2013-09-30 20:45:44 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libunwind-debug-frame.bin:
|
2013-12-10 20:24:04 +08:00
|
|
|
$(BUILD) -lelf
|
2016-05-10 15:40:31 +08:00
|
|
|
$(OUTPUT)test-libunwind-x86.bin:
|
|
|
|
|
$(BUILD) -lelf -lunwind-x86
|
|
|
|
|
|
|
|
|
|
$(OUTPUT)test-libunwind-x86_64.bin:
|
|
|
|
|
$(BUILD) -lelf -lunwind-x86_64
|
|
|
|
|
|
|
|
|
|
$(OUTPUT)test-libunwind-arm.bin:
|
|
|
|
|
$(BUILD) -lelf -lunwind-arm
|
|
|
|
|
|
|
|
|
|
$(OUTPUT)test-libunwind-aarch64.bin:
|
|
|
|
|
$(BUILD) -lelf -lunwind-aarch64
|
|
|
|
|
|
2016-05-10 15:40:32 +08:00
|
|
|
$(OUTPUT)test-libunwind-debug-frame-arm.bin:
|
|
|
|
|
$(BUILD) -lelf -lunwind-arm
|
|
|
|
|
|
|
|
|
|
$(OUTPUT)test-libunwind-debug-frame-aarch64.bin:
|
|
|
|
|
$(BUILD) -lelf -lunwind-aarch64
|
2013-11-14 15:25:24 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libaudit.bin:
|
2013-09-30 20:55:31 +08:00
|
|
|
$(BUILD) -laudit
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libslang.bin:
|
2019-06-15 02:39:47 +08:00
|
|
|
$(BUILD) -lslang
|
2013-09-30 20:57:54 +08:00
|
|
|
|
2019-06-19 04:43:35 +08:00
|
|
|
$(OUTPUT)test-libslang-include-subdir.bin:
|
|
|
|
|
$(BUILD) -lslang
|
|
|
|
|
|
2021-04-28 17:20:23 +08:00
|
|
|
$(OUTPUT)test-libtraceevent.bin:
|
|
|
|
|
$(BUILD) -ltraceevent
|
|
|
|
|
|
2021-09-23 08:10:21 +08:00
|
|
|
$(OUTPUT)test-libtracefs.bin:
|
2023-07-11 21:53:38 +08:00
|
|
|
$(BUILD) $(shell $(PKG_CONFIG) --cflags libtraceevent 2>/dev/null) -ltracefs
|
2021-09-23 08:10:21 +08:00
|
|
|
|
2015-11-30 17:02:21 +08:00
|
|
|
$(OUTPUT)test-libcrypto.bin:
|
|
|
|
|
$(BUILD) -lcrypto
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-gtk2.bin:
|
2020-01-13 18:43:58 +08:00
|
|
|
$(BUILD) $(shell $(PKG_CONFIG) --libs --cflags gtk+-2.0 2>/dev/null) -Wno-deprecated-declarations
|
2013-09-30 21:01:56 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-gtk2-infobar.bin:
|
2014-01-15 18:44:08 +08:00
|
|
|
$(BUILD) $(shell $(PKG_CONFIG) --libs --cflags gtk+-2.0 2>/dev/null)
|
2013-09-30 21:08:30 +08:00
|
|
|
|
2013-09-30 21:15:36 +08:00
|
|
|
grep-libs = $(filter -l%,$(1))
|
|
|
|
|
strip-libs = $(filter-out -l%,$(1))
|
|
|
|
|
|
|
|
|
|
PERL_EMBED_LDOPTS = $(shell perl -MExtUtils::Embed -e ldopts 2>/dev/null)
|
|
|
|
|
PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS))
|
|
|
|
|
PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
|
2022-04-05 04:28:48 +08:00
|
|
|
PERL_EMBED_CCOPTS = $(shell perl -MExtUtils::Embed -e ccopts 2>/dev/null)
|
2013-09-30 21:15:36 +08:00
|
|
|
FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
|
|
|
|
|
|
tools build: Filter out options and warnings not supported by clang
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-05 21:33:21 +08:00
|
|
|
ifeq ($(CC_NO_CLANG), 0)
|
|
|
|
|
PERL_EMBED_LDOPTS := $(filter-out -specs=%,$(PERL_EMBED_LDOPTS))
|
|
|
|
|
PERL_EMBED_CCOPTS := $(filter-out -flto=auto -ffat-lto-objects, $(PERL_EMBED_CCOPTS))
|
|
|
|
|
PERL_EMBED_CCOPTS := $(filter-out -specs=%,$(PERL_EMBED_CCOPTS))
|
|
|
|
|
FLAGS_PERL_EMBED += -Wno-compound-token-split-by-macro
|
|
|
|
|
endif
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libperl.bin:
|
2013-09-30 21:15:36 +08:00
|
|
|
$(BUILD) $(FLAGS_PERL_EMBED)
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libpython.bin:
|
2017-04-12 14:49:13 +08:00
|
|
|
$(BUILD) $(FLAGS_PYTHON_EMBED)
|
2013-09-30 21:18:37 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libbfd.bin:
|
tools, build: Retry detection of bfd-related features
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-07-20 01:05:52 +08:00
|
|
|
$(BUILD_BFD)
|
2013-09-30 21:53:31 +08:00
|
|
|
|
2020-09-04 00:44:39 +08:00
|
|
|
$(OUTPUT)test-libbfd-buildid.bin:
|
tools, build: Retry detection of bfd-related features
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-07-20 01:05:52 +08:00
|
|
|
$(BUILD_BFD) || $(BUILD_BFD) -liberty || $(BUILD_BFD) -liberty -lz
|
2020-09-04 00:44:39 +08:00
|
|
|
|
2017-12-28 03:16:29 +08:00
|
|
|
$(OUTPUT)test-disassembler-four-args.bin:
|
tools, build: Retry detection of bfd-related features
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-07-20 01:05:52 +08:00
|
|
|
$(BUILD_BFD) -lopcodes || $(BUILD_BFD) -lopcodes -liberty || \
|
|
|
|
|
$(BUILD_BFD) -lopcodes -liberty -lz
|
2017-12-28 03:16:29 +08:00
|
|
|
|
2022-08-01 09:38:27 +08:00
|
|
|
$(OUTPUT)test-disassembler-init-styled.bin:
|
tools, build: Retry detection of bfd-related features
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-07-20 01:05:52 +08:00
|
|
|
$(BUILD_BFD) -lopcodes || $(BUILD_BFD) -lopcodes -liberty || \
|
|
|
|
|
$(BUILD_BFD) -lopcodes -liberty -lz
|
2022-08-01 09:38:27 +08:00
|
|
|
|
2018-07-11 05:43:05 +08:00
|
|
|
$(OUTPUT)test-reallocarray.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2018-11-16 08:32:01 +08:00
|
|
|
$(OUTPUT)test-libbfd-liberty.bin:
|
2015-12-15 23:39:32 +08:00
|
|
|
$(CC) $(CFLAGS) -Wall -Werror -o $@ test-libbfd.c -DPACKAGE='"perf"' $(LDFLAGS) -lbfd -ldl -liberty
|
2013-10-02 21:15:09 +08:00
|
|
|
|
2018-11-16 08:32:01 +08:00
|
|
|
$(OUTPUT)test-libbfd-liberty-z.bin:
|
2015-12-15 23:39:32 +08:00
|
|
|
$(CC) $(CFLAGS) -Wall -Werror -o $@ test-libbfd.c -DPACKAGE='"perf"' $(LDFLAGS) -lbfd -ldl -liberty -lz
|
2013-10-02 21:15:09 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-cplus-demangle.bin:
|
2013-10-02 21:15:09 +08:00
|
|
|
$(BUILD) -liberty
|
|
|
|
|
|
2023-03-11 14:57:48 +08:00
|
|
|
$(OUTPUT)test-cxa-demangle.bin:
|
|
|
|
|
$(BUILDXX)
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-backtrace.bin:
|
2013-09-30 22:49:38 +08:00
|
|
|
$(BUILD)
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-timerfd.bin:
|
2013-10-30 00:43:16 +08:00
|
|
|
$(BUILD)
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libdw-dwarf-unwind.bin:
|
2015-02-21 06:16:58 +08:00
|
|
|
$(BUILD) # -ldw provided by $(FEATURE_CHECK_LDFLAGS-libdw-dwarf-unwind)
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-libbabeltrace.bin:
|
2015-02-21 06:16:58 +08:00
|
|
|
$(BUILD) # -lbabeltrace provided by $(FEATURE_CHECK_LDFLAGS-libbabeltrace)
|
2014-02-19 23:52:56 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-compile-32.bin:
|
|
|
|
|
$(CC) -m32 -o $@ test-compile.c
|
2014-10-24 05:16:03 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-compile-x32.bin:
|
|
|
|
|
$(CC) -mx32 -o $@ test-compile.c
|
2014-10-24 05:16:03 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-zlib.bin:
|
perf tools: Add gzip decompression support for kernel module
Now my Archlinux box shows module symbols correctly.
Before:
$ perf report --stdio
Failed to open /tmp/perf-3477.map, continuing without symbols
no symbols found in /usr/bin/date, maybe install a debug package?
No kallsyms or vmlinux with build-id 7b4ea0a49ae2111925857099aaf05c3246ff33e0 was found
[drm] with build id 7b4ea0a49ae2111925857099aaf05c3246ff33e0 not found, continuing without symbols
No kallsyms or vmlinux with build-id edd931629094b660ca9dec09a1b635c8d87aa2ee was found
[jbd2] with build id edd931629094b660ca9dec09a1b635c8d87aa2ee not found, continuing without symbols
No kallsyms or vmlinux with build-id a7b1eada671c34933e5610bb920b2ca4945a82c3 was found
[ext4] with build id a7b1eada671c34933e5610bb920b2ca4945a82c3 not found, continuing without symbols
No kallsyms or vmlinux with build-id d69511fa3e5840e770336ef45b06c83fef8d74e3 was found
[scsi_mod] with build id d69511fa3e5840e770336ef45b06c83fef8d74e3 not found, continuing without symbols
No kallsyms or vmlinux with build-id af0430af13461af058770ee9b87afc07922c2e77 was found
[libata] with build id af0430af13461af058770ee9b87afc07922c2e77 not found, continuing without symbols
No kallsyms or vmlinux with build-id aaeedff8160ce631a5f0333591c6ff291201d29f was found
[libahci] with build id aaeedff8160ce631a5f0333591c6ff291201d29f not found, continuing without symbols
No kallsyms or vmlinux with build-id c57907712becaf662dc4981824bb372c0441d605 was found
[mac80211] with build id c57907712becaf662dc4981824bb372c0441d605 not found, continuing without symbols
No kallsyms or vmlinux with build-id e0589077cc0ec8c3e4c40eb9f2d9e69d236bee8f was found
[iwldvm] with build id e0589077cc0ec8c3e4c40eb9f2d9e69d236bee8f not found, continuing without symbols
No kallsyms or vmlinux with build-id 2d86086bf136bf374a2f029cf85a48194f9b950b was found
[cfg80211] with build id 2d86086bf136bf374a2f029cf85a48194f9b950b not found, continuing without symbols
No kallsyms or vmlinux with build-id 4493c48599bdb3d91d0f8db5150e0be33fdd9221 was found
[iwlwifi] with build id 4493c48599bdb3d91d0f8db5150e0be33fdd9221 not found, continuing without symbols
...
#
# Overhead Command Shared Object Symbol
# ........ ............... ....................... ........................................................
#
0.03% swapper [ext4] [k] 0x000000000000fe2e
0.03% swapper [kernel.kallsyms] [k] account_entity_enqueue
0.03% swapper [ext4] [k] 0x000000000000fc2b
0.03% irq/50-iwlwifi [iwlwifi] [k] 0x000000000000200b
0.03% swapper [kernel.kallsyms] [k] ktime_add_safe
0.03% swapper [kernel.kallsyms] [k] elv_completed_request
0.03% swapper [libata] [k] 0x0000000000003997
0.03% swapper [libahci] [k] 0x0000000000001f25
0.03% swapper [kernel.kallsyms] [k] rb_next
0.03% swapper [kernel.kallsyms] [k] blk_finish_request
0.03% swapper [ext4] [k] 0x0000000000010248
0.00% perf [kernel.kallsyms] [k] native_write_msr_safe
After:
$ perf report --stdio
Failed to open /tmp/perf-3477.map, continuing without symbols
no symbols found in /usr/bin/tr, maybe install a debug package?
...
#
# Overhead Command Shared Object Symbol
# ........ ............... ........................... ......................................................
#
0.04% kworker/u16:3 [ext4] [k] ext4_read_block_bitmap
0.03% kworker/u16:0 [mac80211] [k] ieee80211_sta_reset_beacon_monitor
0.02% irq/50-iwlwifi [mac80211] [k] ieee80211_get_bssid
0.02% firefox [e1000e] [k] __ew32_prepare
0.02% swapper [libahci] [k] ahci_handle_port_interrupt
0.02% emacs libglib-2.0.so.0.4000.0 [.] g_mutex_unlock
0.02% swapper [e1000e] [k] e1000_clean_tx_irq
0.02% dwm [kernel.kallsyms] [k] __schedule
0.02% gnome-terminal- [vdso] [.] __vdso_clock_gettime
0.02% swapper [e1000e] [k] e1000_alloc_rx_buffers
0.02% irq/50-iwlwifi [mac80211] [k] ieee80211_rx
0.01% firefox [vdso] [.] __vdso_gettimeofday
0.01% irq/50-iwlwifi [iwlwifi] [k] iwl_pcie_rxq_restock.part.13
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/87h9yexshi.fsf@sejong.aot.lge.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2014-10-31 15:51:38 +08:00
|
|
|
$(BUILD) -lz
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-lzma.bin:
|
2015-03-04 18:35:47 +08:00
|
|
|
$(BUILD) -llzma
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-get_cpuid.bin:
|
2015-09-17 23:54:30 +08:00
|
|
|
$(BUILD)
|
|
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
$(OUTPUT)test-bpf.bin:
|
bpf tools: Introduce 'bpf' library and add bpf feature check
This is the first patch of libbpf. The goal of libbpf is to create a
standard way for accessing eBPF object files. This patch creates
'Makefile' and 'Build' for it, allows 'make' to build libbpf.a and
libbpf.so, 'make install' to put them into proper directories.
Most part of Makefile is borrowed from traceevent.
Before building, it checks the existence of libelf in Makefile, and deny
to build if not found. Instead of throwing an error if libelf not found,
the error raises in a phony target "elfdep". This design is to ensure
'make clean' still workable even if libelf is not found.
Because libbpf requires 'kern_version' field set for 'union bpf_attr'
(bpfdep" is used for that dependency), Kernel BPF API is also checked
by intruducing a new feature check 'bpf' into tools/build/feature,
which checks the existence and version of linux/bpf.h. When building
libbpf, it searches that file from include/uapi/linux in kernel source
tree (controlled by FEATURE_CHECK_CFLAGS-bpf). Since it searches kernel
source tree it reside, installing of newest kernel headers is not
required, except we are trying to port these files to an old kernel.
To avoid checking that file when perf building, the newly introduced
'bpf' feature check doesn't added into FEATURE_TESTS and
FEATURE_DISPLAY by default in tools/build/Makefile.feature, but added
into libbpf's specific.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kaixu Xia <xiakaixu@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Zefan Li <lizefan@huawei.com>
Bcc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1435716878-189507-4-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-07-01 10:13:51 +08:00
|
|
|
$(BUILD)
|
|
|
|
|
|
2019-11-26 20:12:53 +08:00
|
|
|
$(OUTPUT)test-libbpf.bin:
|
|
|
|
|
$(BUILD) -lbpf
|
|
|
|
|
|
perf build: Fix check for btf__load_from_kernel_by_id() in libbpf
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-05-20 08:25:12 +08:00
|
|
|
$(OUTPUT)test-libbpf-btf__load_from_kernel_by_id.bin:
|
|
|
|
|
$(BUILD) -lbpf
|
|
|
|
|
|
perf build: Stop using __weak bpf_prog_load() to handle older libbpf versions
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-24 19:04:43 +08:00
|
|
|
$(OUTPUT)test-libbpf-bpf_prog_load.bin:
|
|
|
|
|
$(BUILD) -lbpf
|
|
|
|
|
|
perf build: Stop using __weak bpf_map_create() to handle older libbpf versions
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-26 22:48:58 +08:00
|
|
|
$(OUTPUT)test-libbpf-bpf_map_create.bin:
|
|
|
|
|
$(BUILD) -lbpf
|
|
|
|
|
|
perf build: Stop using __weak bpf_object__next_program() to handle older 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-24 19:09:42 +08:00
|
|
|
$(OUTPUT)test-libbpf-bpf_object__next_program.bin:
|
|
|
|
|
$(BUILD) -lbpf
|
|
|
|
|
|
perf build: Stop using __weak bpf_object__next_map() to handle older libbpf 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-24 19:13:17 +08:00
|
|
|
$(OUTPUT)test-libbpf-bpf_object__next_map.bin:
|
|
|
|
|
$(BUILD) -lbpf
|
|
|
|
|
|
2022-10-19 20:44:17 +08:00
|
|
|
$(OUTPUT)test-libbpf-bpf_program__set_insns.bin:
|
|
|
|
|
$(BUILD) -lbpf
|
|
|
|
|
|
perf build: Stop using __weak btf__raw_data() to handle older libbpf versions
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-24 19:16:20 +08:00
|
|
|
$(OUTPUT)test-libbpf-btf__raw_data.bin:
|
|
|
|
|
$(BUILD) -lbpf
|
|
|
|
|
|
2016-07-12 18:05:56 +08:00
|
|
|
$(OUTPUT)test-sdt.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2016-09-26 15:26:56 +08:00
|
|
|
$(OUTPUT)test-cxx.bin:
|
|
|
|
|
$(BUILDXX) -std=gnu++11
|
|
|
|
|
|
2019-06-13 23:04:19 +08:00
|
|
|
$(OUTPUT)test-gettid.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2016-11-02 21:35:48 +08:00
|
|
|
$(OUTPUT)test-jvmti.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2018-11-21 23:43:41 +08:00
|
|
|
$(OUTPUT)test-jvmti-cmlr.bin:
|
|
|
|
|
$(BUILD)
|
|
|
|
|
|
2016-11-26 15:03:31 +08:00
|
|
|
$(OUTPUT)test-llvm.bin:
|
2023-07-25 23:03:46 +08:00
|
|
|
$(BUILDXX) -std=gnu++17 \
|
2016-11-26 15:03:31 +08:00
|
|
|
-I$(shell $(LLVM_CONFIG) --includedir) \
|
|
|
|
|
-L$(shell $(LLVM_CONFIG) --libdir) \
|
|
|
|
|
$(shell $(LLVM_CONFIG) --libs Core BPF) \
|
2018-03-07 23:50:20 +08:00
|
|
|
$(shell $(LLVM_CONFIG) --system-libs) \
|
|
|
|
|
> $(@:.bin=.make.output) 2>&1
|
2016-11-26 15:03:31 +08:00
|
|
|
|
perf build: Check LLVM version in feature check
Cancel builtin llvm and clang support when LLVM version is less than
3.9.0: following commits uses newer API.
Since Clang/LLVM's API is not guaranteed to be stable, add a
test-llvm-version.cpp feature checker, issue warning if LLVM found in
compiling environment is not tested yet.
Committer Notes:
Testing it:
Environment:
$ cat /etc/fedora-release
Fedora release 25 (Twenty Five)
$ rpm -q llvm-devel clang-devel
llvm-devel-3.8.0-1.fc25.x86_64
clang-devel-3.8.0-2.fc25.x86_64
$
Before:
$ make -k LIBCLANGLLVM=1 O=/tmp/build/perf -C tools/perf install-bin
make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD: Doing 'make -j4' parallel build
Warning: tools/include/uapi/linux/bpf.h differs from kernel
Warning: tools/arch/arm/include/uapi/asm/kvm.h differs from kernel
INSTALL GTK UI
LINK /tmp/build/perf/perf
/tmp/build/perf/libperf.a(libperf-in.o): In function `perf::createCompilerInvocation(llvm::SmallVector<char const*, 16u>, llvm::StringRef&, clang::DiagnosticsEngine&)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:56: undefined reference to `clang::tooling::newInvocation(clang::DiagnosticsEngine*, llvm::SmallVector<char const*, 16u> const&)'
/tmp/build/perf/libperf.a(libperf-in.o): In function `perf::getModuleFromSource(llvm::SmallVector<char const*, 16u>, llvm::StringRef, llvm::IntrusiveRefCntPtr<clang::vfs::FileSystem>)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:68: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, bool)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:69: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'
<SNIP>
After:
Makefile.config:807: No suitable libLLVM found, disabling builtin clang and llvm support. Please install llvm-dev(el) (>= 3.9.0)
Updating the environment to a locally built LLVM 4.0 + clang 3.9 (forgot
to git pull, duh) combo, all works as expected, it is properly detected
and built into the resulting perf binary.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Reported-and-Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Joe Stringer <joe@ovn.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/20161206072230.7651-1-wangnan0@huawei.com
[ Change the warning message a bit (add 'suitable' and 'builtin'), clarifying it, see committer notes above ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-12-06 15:22:30 +08:00
|
|
|
$(OUTPUT)test-llvm-version.bin:
|
2023-07-25 23:03:46 +08:00
|
|
|
$(BUILDXX) -std=gnu++17 \
|
2018-03-07 23:50:20 +08:00
|
|
|
-I$(shell $(LLVM_CONFIG) --includedir) \
|
|
|
|
|
> $(@:.bin=.make.output) 2>&1
|
perf build: Check LLVM version in feature check
Cancel builtin llvm and clang support when LLVM version is less than
3.9.0: following commits uses newer API.
Since Clang/LLVM's API is not guaranteed to be stable, add a
test-llvm-version.cpp feature checker, issue warning if LLVM found in
compiling environment is not tested yet.
Committer Notes:
Testing it:
Environment:
$ cat /etc/fedora-release
Fedora release 25 (Twenty Five)
$ rpm -q llvm-devel clang-devel
llvm-devel-3.8.0-1.fc25.x86_64
clang-devel-3.8.0-2.fc25.x86_64
$
Before:
$ make -k LIBCLANGLLVM=1 O=/tmp/build/perf -C tools/perf install-bin
make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD: Doing 'make -j4' parallel build
Warning: tools/include/uapi/linux/bpf.h differs from kernel
Warning: tools/arch/arm/include/uapi/asm/kvm.h differs from kernel
INSTALL GTK UI
LINK /tmp/build/perf/perf
/tmp/build/perf/libperf.a(libperf-in.o): In function `perf::createCompilerInvocation(llvm::SmallVector<char const*, 16u>, llvm::StringRef&, clang::DiagnosticsEngine&)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:56: undefined reference to `clang::tooling::newInvocation(clang::DiagnosticsEngine*, llvm::SmallVector<char const*, 16u> const&)'
/tmp/build/perf/libperf.a(libperf-in.o): In function `perf::getModuleFromSource(llvm::SmallVector<char const*, 16u>, llvm::StringRef, llvm::IntrusiveRefCntPtr<clang::vfs::FileSystem>)':
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:68: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, bool)'
/home/acme/git/linux/tools/perf/util/c++/clang.cpp:69: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'
<SNIP>
After:
Makefile.config:807: No suitable libLLVM found, disabling builtin clang and llvm support. Please install llvm-dev(el) (>= 3.9.0)
Updating the environment to a locally built LLVM 4.0 + clang 3.9 (forgot
to git pull, duh) combo, all works as expected, it is properly detected
and built into the resulting perf binary.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Reported-and-Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Joe Stringer <joe@ovn.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/20161206072230.7651-1-wangnan0@huawei.com
[ Change the warning message a bit (add 'suitable' and 'builtin'), clarifying it, see committer notes above ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-12-06 15:22:30 +08:00
|
|
|
|
2016-11-26 15:03:32 +08:00
|
|
|
$(OUTPUT)test-clang.bin:
|
2023-07-25 23:03:46 +08:00
|
|
|
$(BUILDXX) -std=gnu++17 \
|
2016-11-26 15:03:32 +08:00
|
|
|
-I$(shell $(LLVM_CONFIG) --includedir) \
|
|
|
|
|
-L$(shell $(LLVM_CONFIG) --libdir) \
|
2023-07-25 23:03:46 +08:00
|
|
|
-Wl,--start-group -lclang-cpp -Wl,--end-group \
|
2016-11-26 15:03:32 +08:00
|
|
|
$(shell $(LLVM_CONFIG) --libs Core option) \
|
2018-03-07 23:50:20 +08:00
|
|
|
$(shell $(LLVM_CONFIG) --system-libs) \
|
|
|
|
|
> $(@:.bin=.make.output) 2>&1
|
2016-11-26 15:03:32 +08:00
|
|
|
|
2015-12-15 23:39:32 +08:00
|
|
|
-include $(OUTPUT)*.d
|
2013-09-30 19:51:28 +08:00
|
|
|
|
2018-11-06 17:03:35 +08:00
|
|
|
$(OUTPUT)test-libaio.bin:
|
|
|
|
|
$(BUILD) -lrt
|
|
|
|
|
|
2019-03-19 01:39:49 +08:00
|
|
|
$(OUTPUT)test-libzstd.bin:
|
|
|
|
|
$(BUILD) -lzstd
|
|
|
|
|
|
2020-06-20 07:17:00 +08:00
|
|
|
$(OUTPUT)test-clang-bpf-co-re.bin:
|
2023-06-24 08:18:56 +08:00
|
|
|
$(CLANG) -S -g --target=bpf -o - $(patsubst %.bin,%.c,$(@F)) | \
|
2020-03-13 02:23:30 +08:00
|
|
|
grep BTF_KIND_VAR
|
|
|
|
|
|
2020-04-02 09:52:49 +08:00
|
|
|
$(OUTPUT)test-file-handle.bin:
|
|
|
|
|
$(BUILD)
|
2020-03-13 02:23:30 +08:00
|
|
|
|
2020-04-30 07:14:41 +08:00
|
|
|
$(OUTPUT)test-libpfm4.bin:
|
|
|
|
|
$(BUILD) -lpfm
|
|
|
|
|
|
2013-09-30 16:08:24 +08:00
|
|
|
###############################
|
|
|
|
|
|
|
|
|
|
clean:
|
2015-12-15 23:39:32 +08:00
|
|
|
rm -f $(FILES) $(OUTPUT)*.d $(FILES:.bin=.make.output)
|