2019-05-19 12:07:45 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2017-10-05 03:10:04 +00:00
|
|
|
include ../../scripts/Makefile.include
|
|
|
|
|
include ../../scripts/utilities.mak
|
|
|
|
|
|
|
|
|
|
ifeq ($(srctree),)
|
|
|
|
|
srctree := $(patsubst %/,%,$(dir $(CURDIR)))
|
|
|
|
|
srctree := $(patsubst %/,%,$(dir $(srctree)))
|
|
|
|
|
srctree := $(patsubst %/,%,$(dir $(srctree)))
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(V),1)
|
|
|
|
|
Q =
|
|
|
|
|
else
|
|
|
|
|
Q = @
|
|
|
|
|
endif
|
|
|
|
|
|
2021-10-09 21:03:39 +00:00
|
|
|
BPF_DIR = $(srctree)/tools/lib/bpf
|
2017-10-05 03:10:04 +00:00
|
|
|
|
|
|
|
|
ifneq ($(OUTPUT),)
|
2021-10-07 19:44:29 +00:00
|
|
|
_OUTPUT := $(OUTPUT)
|
2017-10-05 03:10:04 +00:00
|
|
|
else
|
2021-10-07 19:44:29 +00:00
|
|
|
_OUTPUT := $(CURDIR)
|
2017-10-05 03:10:04 +00:00
|
|
|
endif
|
2021-10-07 19:44:29 +00:00
|
|
|
BOOTSTRAP_OUTPUT := $(_OUTPUT)/bootstrap/
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
|
2021-10-07 19:44:29 +00:00
|
|
|
LIBBPF_OUTPUT := $(_OUTPUT)/libbpf/
|
|
|
|
|
LIBBPF_DESTDIR := $(LIBBPF_OUTPUT)
|
|
|
|
|
LIBBPF_INCLUDE := $(LIBBPF_DESTDIR)/include
|
2021-10-09 21:03:39 +00:00
|
|
|
LIBBPF_HDRS_DIR := $(LIBBPF_INCLUDE)/bpf
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
LIBBPF := $(LIBBPF_OUTPUT)libbpf.a
|
2017-10-05 03:10:04 +00:00
|
|
|
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
LIBBPF_BOOTSTRAP_OUTPUT := $(BOOTSTRAP_OUTPUT)libbpf/
|
|
|
|
|
LIBBPF_BOOTSTRAP_DESTDIR := $(LIBBPF_BOOTSTRAP_OUTPUT)
|
|
|
|
|
LIBBPF_BOOTSTRAP_INCLUDE := $(LIBBPF_BOOTSTRAP_DESTDIR)/include
|
|
|
|
|
LIBBPF_BOOTSTRAP_HDRS_DIR := $(LIBBPF_BOOTSTRAP_INCLUDE)/bpf
|
|
|
|
|
LIBBPF_BOOTSTRAP := $(LIBBPF_BOOTSTRAP_OUTPUT)libbpf.a
|
2017-10-05 03:10:04 +00:00
|
|
|
|
bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects
In order to show pinned paths for BPF programs, maps, or links when
listing them with the "-f" option, bpftool creates hash maps to store
all relevant paths under the bpffs. So far, it would rely on the
kernel implementation (from tools/include/linux/hashtable.h).
We can make bpftool rely on libbpf's implementation instead. The
motivation is to make bpftool less dependent of kernel headers, to ease
the path to a potential out-of-tree mirror, like libbpf has.
This commit is the first step of the conversion: the hash maps for
pinned paths for programs, maps, and links are converted to libbpf's
hashmap.{c,h}. Other hash maps used for the PIDs of process holding
references to BPF objects are left unchanged for now. On the build side,
this requires adding a dependency to a second header internal to libbpf,
and making it a dependency for the bootstrap bpftool version as well.
The rest of the changes are a rather straightforward conversion.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-4-quentin@isovalent.com
2021-10-23 20:51:52 +00:00
|
|
|
# We need to copy hashmap.h and nlattr.h which is not otherwise exported by
|
|
|
|
|
# libbpf, but still required by bpftool.
|
|
|
|
|
LIBBPF_INTERNAL_HDRS := $(addprefix $(LIBBPF_HDRS_DIR)/,hashmap.h nlattr.h)
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
LIBBPF_BOOTSTRAP_INTERNAL_HDRS := $(addprefix $(LIBBPF_BOOTSTRAP_HDRS_DIR)/,hashmap.h)
|
2021-10-07 19:44:29 +00:00
|
|
|
|
2020-11-10 16:43:11 +00:00
|
|
|
ifeq ($(BPFTOOL_VERSION),)
|
|
|
|
|
BPFTOOL_VERSION := $(shell make -rR --no-print-directory -sC ../../.. kernelversion)
|
|
|
|
|
endif
|
2017-12-27 19:16:28 +00:00
|
|
|
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
$(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DIR) $(LIBBPF_BOOTSTRAP_HDRS_DIR):
|
2020-11-10 16:43:06 +00:00
|
|
|
$(QUIET_MKDIR)mkdir -p $@
|
|
|
|
|
|
2021-10-09 21:03:40 +00:00
|
|
|
$(LIBBPF): $(wildcard $(BPF_DIR)/*.[ch] $(BPF_DIR)/Makefile) | $(LIBBPF_OUTPUT)
|
2021-10-07 19:44:29 +00:00
|
|
|
$(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(LIBBPF_OUTPUT) \
|
|
|
|
|
DESTDIR=$(LIBBPF_DESTDIR) prefix= $(LIBBPF) install_headers
|
|
|
|
|
|
2021-10-23 20:51:50 +00:00
|
|
|
$(LIBBPF_INTERNAL_HDRS): $(LIBBPF_HDRS_DIR)/%.h: $(BPF_DIR)/%.h | $(LIBBPF_HDRS_DIR)
|
2021-10-09 21:03:39 +00:00
|
|
|
$(call QUIET_INSTALL, $@)
|
|
|
|
|
$(Q)install -m 644 -t $(LIBBPF_HDRS_DIR) $<
|
2017-10-05 03:10:04 +00:00
|
|
|
|
2021-10-09 21:03:40 +00:00
|
|
|
$(LIBBPF_BOOTSTRAP): $(wildcard $(BPF_DIR)/*.[ch] $(BPF_DIR)/Makefile) | $(LIBBPF_BOOTSTRAP_OUTPUT)
|
2020-11-10 16:43:07 +00:00
|
|
|
$(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(LIBBPF_BOOTSTRAP_OUTPUT) \
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
DESTDIR=$(LIBBPF_BOOTSTRAP_DESTDIR) prefix= \
|
|
|
|
|
ARCH= CC=$(HOSTCC) LD=$(HOSTLD) $@ install_headers
|
|
|
|
|
|
|
|
|
|
$(LIBBPF_BOOTSTRAP_INTERNAL_HDRS): $(LIBBPF_BOOTSTRAP_HDRS_DIR)/%.h: $(BPF_DIR)/%.h | $(LIBBPF_BOOTSTRAP_HDRS_DIR)
|
|
|
|
|
$(call QUIET_INSTALL, $@)
|
|
|
|
|
$(Q)install -m 644 -t $(LIBBPF_BOOTSTRAP_HDRS_DIR) $<
|
2020-11-10 16:43:07 +00:00
|
|
|
|
2020-11-12 09:10:52 +00:00
|
|
|
$(LIBBPF)-clean: FORCE | $(LIBBPF_OUTPUT)
|
2017-10-05 03:10:04 +00:00
|
|
|
$(call QUIET_CLEAN, libbpf)
|
tools: bpftool: improve and check builds for different make invocations
There are a number of alternative "make" invocations that can be used to
compile bpftool. The following invocations are expected to work:
- through the kbuild system, from the top of the repository
(make tools/bpf)
- by telling make to change to the bpftool directory
(make -C tools/bpf/bpftool)
- by building the BPF tools from tools/
(cd tools && make bpf)
- by running make from bpftool directory
(cd tools/bpf/bpftool && make)
Additionally, setting the O or OUTPUT variables should tell the build
system to use a custom output path, for each of these alternatives.
The following patch fixes the following invocations:
$ make tools/bpf
$ make tools/bpf O=<dir>
$ make -C tools/bpf/bpftool OUTPUT=<dir>
$ make -C tools/bpf/bpftool O=<dir>
$ cd tools/ && make bpf O=<dir>
$ cd tools/bpf/bpftool && make OUTPUT=<dir>
$ cd tools/bpf/bpftool && make O=<dir>
After this commit, the build still fails for two variants when passing
the OUTPUT variable:
$ make tools/bpf OUTPUT=<dir>
$ cd tools/ && make bpf OUTPUT=<dir>
In order to remember and check what make invocations are supposed to
work, and to document the ones which do not, a new script is added to
the BPF selftests. Note that some invocations require the kernel to be
configured, so the script skips them if no .config file is found.
v2:
- In make_and_clean(), set $ERROR to 1 when "make" returns non-zero,
even if the binary was produced.
- Run "make clean" from the correct directory (bpf/ instead of bpftool/,
when relevant).
Reported-by: Lorenz Bauer <lmb@cloudflare.com>
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-30 11:00:38 +00:00
|
|
|
$(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(LIBBPF_OUTPUT) clean >/dev/null
|
2017-10-05 03:10:04 +00:00
|
|
|
|
2020-11-12 09:10:52 +00:00
|
|
|
$(LIBBPF_BOOTSTRAP)-clean: FORCE | $(LIBBPF_BOOTSTRAP_OUTPUT)
|
2020-11-10 16:43:07 +00:00
|
|
|
$(call QUIET_CLEAN, libbpf-bootstrap)
|
|
|
|
|
$(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(LIBBPF_BOOTSTRAP_OUTPUT) clean >/dev/null
|
|
|
|
|
|
2017-12-07 23:00:17 +00:00
|
|
|
prefix ?= /usr/local
|
tools: bpftool: unify installation directories
Programs and documentation not managed by package manager are generally
installed under /usr/local/, instead of the user's home directory. In
particular, `man` is generally able to find manual pages under
`/usr/local/share/man`.
bpftool generally follows perf's example, and perf installs to home
directory. However bpftool requires root credentials, so it seems
sensible to follow the more common convention of installing files under
/usr/local instead. So, make /usr/local the default prefix for
installing the binary with `make install`, and the documentation with
`make doc-install`. Also, create /usr/local/sbin if it does not exist.
Note that the bash-completion file, however, is still installed under
/usr/share/bash-completion/completions, as the default setup for bash
does not attempt to load completion files under /usr/local/.
Reported-by: David Beckett <david.beckett@netronome.com>
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2017-11-29 01:44:32 +00:00
|
|
|
bash_compdir ?= /usr/share/bash-completion/completions
|
2017-10-05 03:10:04 +00:00
|
|
|
|
|
|
|
|
CFLAGS += -O2
|
2019-08-14 11:37:24 +00:00
|
|
|
CFLAGS += -W -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
|
tools/bpftool: Turn off -Wnested-externs warning
Turn off -Wnested-externs to avoid annoying warnings in BUILD_BUG_ON macro when
compiling bpftool:
In file included from /data/users/andriin/linux/tools/include/linux/build_bug.h:5,
from /data/users/andriin/linux/tools/include/linux/kernel.h:8,
from /data/users/andriin/linux/kernel/bpf/disasm.h:10,
from /data/users/andriin/linux/kernel/bpf/disasm.c:8:
/data/users/andriin/linux/kernel/bpf/disasm.c: In function ‘__func_get_name’:
/data/users/andriin/linux/tools/include/linux/compiler.h:37:38: warning: nested extern declaration of ‘__compiletime_assert_0’ [-Wnested-externs]
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~~~~~~~~~~~~~~~~~~~
/data/users/andriin/linux/tools/include/linux/compiler.h:16:15: note: in definition of macro ‘__compiletime_assert’
extern void prefix ## suffix(void) __compiletime_error(msg); \
^~~~~~
/data/users/andriin/linux/tools/include/linux/compiler.h:37:2: note: in expansion of macro ‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~~~~~~~~~~~~~~~~~
/data/users/andriin/linux/tools/include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
/data/users/andriin/linux/tools/include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
/data/users/andriin/linux/kernel/bpf/disasm.c:20:2: note: in expansion of macro ‘BUILD_BUG_ON’
BUILD_BUG_ON(ARRAY_SIZE(func_id_str) != __BPF_FUNC_MAX_ID);
^~~~~~~~~~~~
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200701212816.2072340-1-andriin@fb.com
2020-07-01 21:28:16 +00:00
|
|
|
CFLAGS += $(filter-out -Wswitch-enum -Wnested-externs,$(EXTRA_WARNINGS))
|
2018-05-04 01:37:16 +00:00
|
|
|
CFLAGS += -DPACKAGE='"bpftool"' -D__EXPORTED_HEADERS__ \
|
2020-06-19 23:17:00 +00:00
|
|
|
-I$(if $(OUTPUT),$(OUTPUT),.) \
|
2021-10-07 19:44:29 +00:00
|
|
|
-I$(LIBBPF_INCLUDE) \
|
2018-05-04 01:37:16 +00:00
|
|
|
-I$(srctree)/kernel/bpf/ \
|
|
|
|
|
-I$(srctree)/tools/include \
|
2021-10-20 09:48:26 +00:00
|
|
|
-I$(srctree)/tools/include/uapi
|
2017-12-27 19:16:28 +00:00
|
|
|
CFLAGS += -DBPFTOOL_VERSION='"$(BPFTOOL_VERSION)"'
|
2018-10-08 08:22:58 +00:00
|
|
|
ifneq ($(EXTRA_CFLAGS),)
|
|
|
|
|
CFLAGS += $(EXTRA_CFLAGS)
|
|
|
|
|
endif
|
2018-10-08 08:22:59 +00:00
|
|
|
ifneq ($(EXTRA_LDFLAGS),)
|
|
|
|
|
LDFLAGS += $(EXTRA_LDFLAGS)
|
|
|
|
|
endif
|
2018-10-08 08:22:58 +00:00
|
|
|
|
2017-12-07 23:00:17 +00:00
|
|
|
INSTALL ?= install
|
|
|
|
|
RM ?= rm -f
|
|
|
|
|
|
2017-12-27 19:16:29 +00:00
|
|
|
FEATURE_USER = .bpftool
|
2020-04-29 14:45:06 +00:00
|
|
|
FEATURE_TESTS = libbfd disassembler-four-args reallocarray zlib libcap \
|
2020-06-19 23:17:00 +00:00
|
|
|
clang-bpf-co-re
|
2020-04-29 14:45:06 +00:00
|
|
|
FEATURE_DISPLAY = libbfd disassembler-four-args zlib libcap \
|
2020-06-19 23:17:00 +00:00
|
|
|
clang-bpf-co-re
|
2017-12-27 19:16:29 +00:00
|
|
|
|
|
|
|
|
check_feat := 1
|
|
|
|
|
NON_CHECK_FEAT_TARGETS := clean uninstall doc doc-clean doc-install doc-uninstall
|
|
|
|
|
ifdef MAKECMDGOALS
|
|
|
|
|
ifeq ($(filter-out $(NON_CHECK_FEAT_TARGETS),$(MAKECMDGOALS)),)
|
|
|
|
|
check_feat := 0
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(check_feat),1)
|
|
|
|
|
ifeq ($(FEATURES_DUMP),)
|
|
|
|
|
include $(srctree)/tools/build/Makefile.feature
|
|
|
|
|
else
|
|
|
|
|
include $(FEATURES_DUMP)
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(feature-disassembler-four-args), 1)
|
|
|
|
|
CFLAGS += -DDISASM_FOUR_ARGS_SIGNATURE
|
|
|
|
|
endif
|
|
|
|
|
|
2018-07-10 21:43:05 +00:00
|
|
|
ifeq ($(feature-reallocarray), 0)
|
|
|
|
|
CFLAGS += -DCOMPAT_NEED_REALLOCARRAY
|
|
|
|
|
endif
|
|
|
|
|
|
2020-04-29 14:45:06 +00:00
|
|
|
LIBS = $(LIBBPF) -lelf -lz
|
2020-11-10 16:43:07 +00:00
|
|
|
LIBS_BOOTSTRAP = $(LIBBPF_BOOTSTRAP) -lelf -lz
|
2020-04-29 14:45:06 +00:00
|
|
|
ifeq ($(feature-libcap), 1)
|
|
|
|
|
CFLAGS += -DUSE_LIBCAP
|
|
|
|
|
LIBS += -lcap
|
|
|
|
|
endif
|
|
|
|
|
|
2018-03-16 06:26:14 +00:00
|
|
|
include $(wildcard $(OUTPUT)*.d)
|
2017-10-05 03:10:04 +00:00
|
|
|
|
|
|
|
|
all: $(OUTPUT)bpftool
|
|
|
|
|
|
2018-11-12 21:44:10 +00:00
|
|
|
BFD_SRCS = jit_disasm.c
|
|
|
|
|
|
|
|
|
|
SRCS = $(filter-out $(BFD_SRCS),$(wildcard *.c))
|
|
|
|
|
|
|
|
|
|
ifeq ($(feature-libbfd),1)
|
2019-01-15 22:03:27 +00:00
|
|
|
LIBS += -lbfd -ldl -lopcodes
|
|
|
|
|
else ifeq ($(feature-libbfd-liberty),1)
|
|
|
|
|
LIBS += -lbfd -ldl -lopcodes -liberty
|
|
|
|
|
else ifeq ($(feature-libbfd-liberty-z),1)
|
|
|
|
|
LIBS += -lbfd -ldl -lopcodes -liberty -lz
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifneq ($(filter -lbfd,$(LIBS)),)
|
2018-11-12 21:44:10 +00:00
|
|
|
CFLAGS += -DHAVE_LIBBFD_SUPPORT
|
|
|
|
|
SRCS += $(BFD_SRCS)
|
|
|
|
|
endif
|
|
|
|
|
|
2020-11-10 16:43:07 +00:00
|
|
|
BPFTOOL_BOOTSTRAP := $(BOOTSTRAP_OUTPUT)bpftool
|
2020-06-19 23:16:59 +00:00
|
|
|
|
2021-06-03 17:05:16 +00:00
|
|
|
BOOTSTRAP_OBJS = $(addprefix $(BOOTSTRAP_OUTPUT),main.o common.o json_writer.o gen.o btf.o xlated_dumper.o btf_dumper.o disasm.o)
|
libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations
Introduce a macro LIBBPF_DEPRECATED_SINCE(major, minor, message) to prepare
the deprecation of two API functions. This macro marks functions as deprecated
when libbpf's version reaches the values passed as an argument.
As part of this change libbpf_version.h header is added with recorded major
(LIBBPF_MAJOR_VERSION) and minor (LIBBPF_MINOR_VERSION) libbpf version macros.
They are now part of libbpf public API and can be relied upon by user code.
libbpf_version.h is installed system-wide along other libbpf public headers.
Due to this new build-time auto-generated header, in-kernel applications
relying on libbpf (resolve_btfids, bpftool, bpf_preload) are updated to
include libbpf's output directory as part of a list of include search paths.
Better fix would be to use libbpf's make_install target to install public API
headers, but that clean up is left out as a future improvement. The build
changes were tested by building kernel (with KBUILD_OUTPUT and O= specified
explicitly), bpftool, libbpf, selftests/bpf, and resolve_btfids builds. No
problems were detected.
Note that because of the constraints of the C preprocessor we have to write
a few lines of macro magic for each version used to prepare deprecation (0.6
for now).
Also, use LIBBPF_DEPRECATED_SINCE() to schedule deprecation of
btf__get_from_id() and btf__load(), which are replaced by
btf__load_from_kernel_by_id() and btf__load_into_kernel(), respectively,
starting from future libbpf v0.6. This is part of libbpf 1.0 effort ([0]).
[0] Closes: https://github.com/libbpf/libbpf/issues/278
Co-developed-by: Quentin Monnet <quentin@isovalent.com>
Co-developed-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20210908213226.1871016-1-andrii@kernel.org
2021-09-08 21:32:26 +00:00
|
|
|
$(BOOTSTRAP_OBJS): $(LIBBPF_BOOTSTRAP)
|
|
|
|
|
|
2017-12-07 23:00:17 +00:00
|
|
|
OBJS = $(patsubst %.c,$(OUTPUT)%.o,$(SRCS)) $(OUTPUT)disasm.o
|
2021-10-09 21:03:39 +00:00
|
|
|
$(OBJS): $(LIBBPF) $(LIBBPF_INTERNAL_HDRS)
|
2020-03-09 17:32:15 +00:00
|
|
|
|
2020-06-30 00:47:58 +00:00
|
|
|
VMLINUX_BTF_PATHS ?= $(if $(O),$(O)/vmlinux) \
|
2020-06-19 23:17:00 +00:00
|
|
|
$(if $(KBUILD_OUTPUT),$(KBUILD_OUTPUT)/vmlinux) \
|
|
|
|
|
../../../vmlinux \
|
|
|
|
|
/sys/kernel/btf/vmlinux \
|
|
|
|
|
/boot/vmlinux-$(shell uname -r)
|
2020-06-30 00:47:58 +00:00
|
|
|
VMLINUX_BTF ?= $(abspath $(firstword $(wildcard $(VMLINUX_BTF_PATHS))))
|
2020-06-19 23:17:00 +00:00
|
|
|
|
2020-12-28 17:40:51 +00:00
|
|
|
bootstrap: $(BPFTOOL_BOOTSTRAP)
|
|
|
|
|
|
2020-06-30 00:47:58 +00:00
|
|
|
ifneq ($(VMLINUX_BTF)$(VMLINUX_H),)
|
2020-06-19 23:17:00 +00:00
|
|
|
ifeq ($(feature-clang-bpf-co-re),1)
|
|
|
|
|
|
|
|
|
|
BUILD_BPF_SKELS := 1
|
|
|
|
|
|
|
|
|
|
$(OUTPUT)vmlinux.h: $(VMLINUX_BTF) $(BPFTOOL_BOOTSTRAP)
|
2020-06-30 00:47:58 +00:00
|
|
|
ifeq ($(VMLINUX_H),)
|
2020-06-19 23:17:00 +00:00
|
|
|
$(QUIET_GEN)$(BPFTOOL_BOOTSTRAP) btf dump file $< format c > $@
|
2020-06-30 00:47:58 +00:00
|
|
|
else
|
|
|
|
|
$(Q)cp "$(VMLINUX_H)" $@
|
|
|
|
|
endif
|
2020-03-12 18:23:30 +00:00
|
|
|
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
$(OUTPUT)%.bpf.o: skeleton/%.bpf.c $(OUTPUT)vmlinux.h $(LIBBPF_BOOTSTRAP)
|
2020-03-12 13:03:30 +00:00
|
|
|
$(QUIET_CLANG)$(CLANG) \
|
2020-06-19 23:17:00 +00:00
|
|
|
-I$(if $(OUTPUT),$(OUTPUT),.) \
|
2020-03-12 13:03:30 +00:00
|
|
|
-I$(srctree)/tools/include/uapi/ \
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
-I$(LIBBPF_BOOTSTRAP_INCLUDE) \
|
2021-01-13 22:36:09 +00:00
|
|
|
-g -O2 -Wall -target bpf -c $< -o $@ && $(LLVM_STRIP) -g $@
|
2020-03-09 17:32:15 +00:00
|
|
|
|
2020-06-19 23:17:00 +00:00
|
|
|
$(OUTPUT)%.skel.h: $(OUTPUT)%.bpf.o $(BPFTOOL_BOOTSTRAP)
|
|
|
|
|
$(QUIET_GEN)$(BPFTOOL_BOOTSTRAP) gen skeleton $< > $@
|
|
|
|
|
|
|
|
|
|
$(OUTPUT)prog.o: $(OUTPUT)profiler.skel.h
|
|
|
|
|
|
tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs
Add bpf_iter-based way to find all the processes that hold open FDs against
BPF object (map, prog, link, btf). bpftool always attempts to discover this,
but will silently give up if kernel doesn't yet support bpf_iter BPF programs.
Process name and PID are emitted for each process (task group).
Sample output for each of 4 BPF objects:
$ sudo ./bpftool prog show
2694: cgroup_device tag 8c42dee26e8cd4c2 gpl
loaded_at 2020-06-16T15:34:32-0700 uid 0
xlated 648B jited 409B memlock 4096B
pids systemd(1)
2907: cgroup_skb name egress tag 9ad187367cf2b9e8 gpl
loaded_at 2020-06-16T18:06:54-0700 uid 0
xlated 48B jited 59B memlock 4096B map_ids 2436
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool map show
2436: array name test_cgr.bss flags 0x400
key 4B value 8B max_entries 1 memlock 8192B
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
2445: array name pid_iter.rodata flags 0x480
key 4B value 4B max_entries 1 memlock 8192B
btf_id 1214 frozen
pids bpftool(2239612)
$ sudo ./bpftool link show
61: cgroup prog 2908
cgroup_id 375301 attach_type egress
pids test_progs(2238417), test_progs(2238445)
62: cgroup prog 2908
cgroup_id 375344 attach_type egress
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool btf show
1202: size 1527B prog_ids 2908,2907 map_ids 2436
pids test_progs(2238417), test_progs(2238445)
1242: size 34684B
pids bpftool(2258892)
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-9-andriin@fb.com
2020-06-19 23:17:02 +00:00
|
|
|
$(OUTPUT)pids.o: $(OUTPUT)pid_iter.skel.h
|
|
|
|
|
|
2020-06-19 23:17:00 +00:00
|
|
|
endif
|
|
|
|
|
endif
|
2020-03-09 17:32:15 +00:00
|
|
|
|
2020-06-23 10:37:10 +00:00
|
|
|
CFLAGS += $(if $(BUILD_BPF_SKELS),,-DBPFTOOL_WITHOUT_SKELETONS)
|
2017-10-09 17:30:13 +00:00
|
|
|
|
2021-06-03 17:05:16 +00:00
|
|
|
$(BOOTSTRAP_OUTPUT)disasm.o: $(srctree)/kernel/bpf/disasm.c
|
|
|
|
|
$(QUIET_CC)$(HOSTCC) $(CFLAGS) -c -MMD -o $@ $<
|
|
|
|
|
|
2017-10-09 17:30:13 +00:00
|
|
|
$(OUTPUT)disasm.o: $(srctree)/kernel/bpf/disasm.c
|
2020-06-02 17:56:48 +00:00
|
|
|
$(QUIET_CC)$(CC) $(CFLAGS) -c -MMD -o $@ $<
|
2017-10-05 03:10:04 +00:00
|
|
|
|
2021-10-09 21:03:41 +00:00
|
|
|
$(OUTPUT)feature.o:
|
|
|
|
|
ifneq ($(feature-zlib), 1)
|
|
|
|
|
$(error "No zlib found")
|
|
|
|
|
endif
|
2019-08-13 00:38:33 +00:00
|
|
|
|
2020-11-10 16:43:07 +00:00
|
|
|
$(BPFTOOL_BOOTSTRAP): $(BOOTSTRAP_OBJS) $(LIBBPF_BOOTSTRAP)
|
|
|
|
|
$(QUIET_LINK)$(HOSTCC) $(CFLAGS) $(LDFLAGS) -o $@ $(BOOTSTRAP_OBJS) \
|
|
|
|
|
$(LIBS_BOOTSTRAP)
|
2020-06-19 23:16:59 +00:00
|
|
|
|
|
|
|
|
$(OUTPUT)bpftool: $(OBJS) $(LIBBPF)
|
|
|
|
|
$(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
|
2017-10-05 03:10:04 +00:00
|
|
|
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
$(BOOTSTRAP_OUTPUT)%.o: %.c $(LIBBPF_BOOTSTRAP_INTERNAL_HDRS) | $(BOOTSTRAP_OUTPUT)
|
|
|
|
|
$(QUIET_CC)$(HOSTCC) \
|
|
|
|
|
$(subst -I$(LIBBPF_INCLUDE),-I$(LIBBPF_BOOTSTRAP_INCLUDE),$(CFLAGS)) \
|
|
|
|
|
-c -MMD -o $@ $<
|
2020-11-10 16:43:07 +00:00
|
|
|
|
2017-10-05 03:10:04 +00:00
|
|
|
$(OUTPUT)%.o: %.c
|
2020-06-02 17:56:48 +00:00
|
|
|
$(QUIET_CC)$(CC) $(CFLAGS) -c -MMD -o $@ $<
|
2017-10-05 03:10:04 +00:00
|
|
|
|
2020-08-27 08:53:36 +00:00
|
|
|
feature-detect-clean:
|
|
|
|
|
$(call QUIET_CLEAN, feature-detect)
|
|
|
|
|
$(Q)$(MAKE) -C $(srctree)/tools/build/feature/ clean >/dev/null
|
|
|
|
|
|
2020-11-10 16:43:07 +00:00
|
|
|
clean: $(LIBBPF)-clean $(LIBBPF_BOOTSTRAP)-clean feature-detect-clean
|
2017-10-05 03:10:04 +00:00
|
|
|
$(call QUIET_CLEAN, bpftool)
|
2019-08-30 11:00:39 +00:00
|
|
|
$(Q)$(RM) -- $(OUTPUT)bpftool $(OUTPUT)*.o $(OUTPUT)*.d
|
2020-11-10 16:43:07 +00:00
|
|
|
$(Q)$(RM) -- $(OUTPUT)*.skel.h $(OUTPUT)vmlinux.h
|
|
|
|
|
$(Q)$(RM) -r -- $(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT)
|
2018-03-16 06:26:17 +00:00
|
|
|
$(call QUIET_CLEAN, core-gen)
|
2019-08-30 11:00:39 +00:00
|
|
|
$(Q)$(RM) -- $(OUTPUT)FEATURE-DUMP.bpftool
|
|
|
|
|
$(Q)$(RM) -r -- $(OUTPUT)feature/
|
2017-10-05 03:10:04 +00:00
|
|
|
|
2021-10-07 19:44:38 +00:00
|
|
|
install-bin: $(OUTPUT)bpftool
|
2017-12-07 23:00:17 +00:00
|
|
|
$(call QUIET_INSTALL, bpftool)
|
|
|
|
|
$(Q)$(INSTALL) -m 0755 -d $(DESTDIR)$(prefix)/sbin
|
|
|
|
|
$(Q)$(INSTALL) $(OUTPUT)bpftool $(DESTDIR)$(prefix)/sbin/bpftool
|
2021-10-07 19:44:38 +00:00
|
|
|
|
|
|
|
|
install: install-bin
|
2017-12-07 23:00:17 +00:00
|
|
|
$(Q)$(INSTALL) -m 0755 -d $(DESTDIR)$(bash_compdir)
|
|
|
|
|
$(Q)$(INSTALL) -m 0644 bash-completion/bpftool $(DESTDIR)$(bash_compdir)
|
2017-10-05 03:10:04 +00:00
|
|
|
|
2017-12-07 23:00:18 +00:00
|
|
|
uninstall:
|
|
|
|
|
$(call QUIET_UNINST, bpftool)
|
2019-08-30 11:00:39 +00:00
|
|
|
$(Q)$(RM) -- $(DESTDIR)$(prefix)/sbin/bpftool
|
|
|
|
|
$(Q)$(RM) -- $(DESTDIR)$(bash_compdir)/bpftool
|
2017-12-07 23:00:18 +00:00
|
|
|
|
2017-10-05 03:10:05 +00:00
|
|
|
doc:
|
2017-12-07 23:00:17 +00:00
|
|
|
$(call descend,Documentation)
|
|
|
|
|
|
|
|
|
|
doc-clean:
|
|
|
|
|
$(call descend,Documentation,clean)
|
2017-10-05 03:10:05 +00:00
|
|
|
|
|
|
|
|
doc-install:
|
2017-12-07 23:00:17 +00:00
|
|
|
$(call descend,Documentation,install)
|
2017-10-05 03:10:05 +00:00
|
|
|
|
2017-12-07 23:00:18 +00:00
|
|
|
doc-uninstall:
|
|
|
|
|
$(call descend,Documentation,uninstall)
|
|
|
|
|
|
2017-10-05 03:10:04 +00:00
|
|
|
FORCE:
|
|
|
|
|
|
2020-06-19 23:17:00 +00:00
|
|
|
.SECONDARY:
|
bpftool: Install libbpf headers for the bootstrap version, too
We recently changed bpftool's Makefile to make it install libbpf's
headers locally instead of pulling them from the source directory of the
library. Although bpftool needs two versions of libbpf, a "regular" one
and a "bootstrap" version, we would only install headers for the regular
libbpf build. Given that this build always occurs before the bootstrap
build when building bpftool, this is enough to ensure that the bootstrap
bpftool will have access to the headers exported through the regular
libbpf build.
However, this did not account for the case when we only want the
bootstrap version of bpftool, through the "bootstrap" target. For
example, perf needs the bootstrap version only, to generate BPF
skeletons. In that case, when are the headers installed? For some time,
the issue has been masked, because we had a step (the installation of
headers internal to libbpf) which would depend on the regular build of
libbpf and hence trigger the export of the headers, just for the sake of
creating a directory. But this changed with commit 8b6c46241c77
("bpftool: Remove Makefile dep. on $(LIBBPF) for
$(LIBBPF_INTERNAL_HDRS)"), where we cleaned up that stage and removed
the dependency on the regular libbpf build. As a result, when we only
want the bootstrap bpftool version, the regular libbpf is no longer
built. The bootstrap libbpf version is built, but headers are not
exported, and the bootstrap bpftool build fails because of the missing
headers.
To fix this, we also install the library headers for the bootstrap
version of libbpf, to use them for the bootstrap bpftool and for
generating the skeletons.
Fixes: f012ade10b34 ("bpftool: Install libbpf headers instead of including the dir")
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20211105015813.6171-1-quentin@isovalent.com
2021-11-05 01:58:13 +00:00
|
|
|
.PHONY: all FORCE bootstrap clean install-bin install uninstall
|
2017-12-07 23:00:18 +00:00
|
|
|
.PHONY: doc doc-clean doc-install doc-uninstall
|
2017-10-05 03:10:04 +00:00
|
|
|
.DEFAULT_GOAL := all
|
