Eduard Zingerman 5a6ea7022f samples/bpf: Remove unnecessary -I flags from libbpf EXTRA_CFLAGS
Commit [0] breaks samples/bpf build:

    $ make M=samples/bpf
    ...
    make -C /path/to/kernel/samples/bpf/../../tools/lib/bpf \
     ...
     EXTRA_CFLAGS=" \
     ...
     -fsanitize=bounds \
     -I/path/to/kernel/usr/include \
     ...
    	/path/to/kernel/samples/bpf/libbpf/libbpf.a install_headers
      CC      /path/to/kernel/samples/bpf/libbpf/staticobjs/libbpf.o
    In file included from libbpf.c:29:
    /path/to/kernel/tools/include/linux/err.h:35:8: error: 'inline' can only appear on functions
       35 | static inline void * __must_check ERR_PTR(long error_)
          |        ^

The error is caused by `objtree` variable changing definition from `.`
(dot) to an absolute path:
- The variable TPROGS_CFLAGS is constructed as follows:
  ...
  TPROGS_CFLAGS += -I$(objtree)/usr/include
- It is passed as EXTRA_CFLAGS for libbpf compilation:
  $(LIBBPF): ...
    ...
	$(MAKE) -C $(LIBBPF_SRC) RM='rm -rf' EXTRA_CFLAGS="$(TPROGS_CFLAGS)"
- Before commit [0], the line passed to libbpf makefile was
  '-I./usr/include', where '.' referred to LIBBPF_SRC due to -C flag.
  The directory $(LIBBPF_SRC)/usr/include does not exist and thus
  was never resolved by C compiler.
- After commit [0], the line passed to libbpf makefile became:
  '<output-dir>/usr/include', this directory exists and is resolved by
  C compiler.
- Both 'tools/include' and 'usr/include' define files err.h and types.h.
- libbpf expects headers like 'linux/err.h' and 'linux/types.h'
  defined in 'tools/include', not 'usr/include', hence the compilation
  error.

This commit removes unnecessary -I flags from libbpf compilation.
(libbpf sets up the necessary includes at lib/bpf/Makefile:63).

Changes v1 [1] -> v2:
- dropped unnecessary replacement of KBUILD_OUTPUT with $(objtree)
  (Andrii)
Changes v2 [2] -> v3:
- make sure --sysroot option is set for libbpf's EXTRA_CFLAGS,
  if $(SYSROOT) is set (Stanislav)

[0] commit 13b25489b6f8 ("kbuild: change working directory to external module directory with M=")
[1] https://lore.kernel.org/bpf/20241202212154.3174402-1-eddyz87@gmail.com/
[2] https://lore.kernel.org/bpf/20241202234741.3492084-1-eddyz87@gmail.com/

Fixes: 13b25489b6f8 ("kbuild: change working directory to external module directory with M=")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://lore.kernel.org/bpf/20241203182222.3915763-1-eddyz87@gmail.com
2024-12-03 13:29:04 -08:00
..
2023-08-24 08:43:50 -07:00
2019-05-31 16:41:29 -07:00
2019-05-31 16:41:29 -07:00
2023-03-13 21:51:30 -07:00
2023-03-13 21:51:30 -07:00
2021-03-25 22:03:46 -07:00
2021-03-25 22:03:46 -07:00

eBPF sample programs
====================

This directory contains a test stubs, verifier test-suite and examples
for using eBPF. The examples use libbpf from tools/lib/bpf.

Note that the XDP-specific samples have been removed from this directory and
moved to the xdp-tools repository: https://github.com/xdp-project/xdp-tools
See the commit messages removing each tool from this directory for how to
convert specific command invocations between the old samples and the utilities
in xdp-tools.

Build dependencies
==================

Compiling requires having installed:
 * clang
 * llvm
 * pahole

Consult :ref:`Documentation/process/changes.rst <changes>` for the minimum
version numbers required and how to update them. Note that LLVM's tool
'llc' must support target 'bpf', list version and supported targets with
command: ``llc --version``

Clean and configuration
-----------------------

It can be needed to clean tools, samples or kernel before trying new arch or
after some changes (on demand)::

 make -C tools clean
 make -C samples/bpf clean
 make clean

Configure kernel, defconfig for instance
(see "tools/testing/selftests/bpf/config" for a reference config)::

 make defconfig

Kernel headers
--------------

There are usually dependencies to header files of the current kernel.
To avoid installing devel kernel headers system wide, as a normal
user, simply call::

 make headers_install

This will create a local "usr/include" directory in the git/build top
level directory, that the make system will automatically pick up first.

Compiling
=========

For building the BPF samples, issue the below command from the kernel
top level directory::

 make M=samples/bpf

It is also possible to call make from this directory.  This will just
hide the invocation of make as above.

Manually compiling LLVM with 'bpf' support
------------------------------------------

Since version 3.7.0, LLVM adds a proper LLVM backend target for the
BPF bytecode architecture.

By default llvm will build all non-experimental backends including bpf.
To generate a smaller llc binary one can use::

 -DLLVM_TARGETS_TO_BUILD="BPF"

We recommend that developers who want the fastest incremental builds
use the Ninja build system, you can find it in your system's package
manager, usually the package is ninja or ninja-build.

Quick sniplet for manually compiling LLVM and clang
(build dependencies are ninja, cmake and gcc-c++)::

 $ git clone https://github.com/llvm/llvm-project.git
 $ mkdir -p llvm-project/llvm/build
 $ cd llvm-project/llvm/build
 $ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
            -DLLVM_ENABLE_PROJECTS="clang"    \
            -DCMAKE_BUILD_TYPE=Release        \
            -DLLVM_BUILD_RUNTIME=OFF
 $ ninja

It is also possible to point make to the newly compiled 'llc' or
'clang' command via redefining LLC or CLANG on the make command line::

 make M=samples/bpf LLC=~/git/llvm-project/llvm/build/bin/llc CLANG=~/git/llvm-project/llvm/build/bin/clang

Cross compiling samples
-----------------------
In order to cross-compile, say for arm64 targets, export CROSS_COMPILE and ARCH
environment variables before calling make. But do this before clean,
configuration and header install steps described above. This will direct make to
build samples for the cross target::

 export ARCH=arm64
 export CROSS_COMPILE="aarch64-linux-gnu-"

Headers can be also installed on RFS of target board if need to keep them in
sync (not necessarily and it creates a local "usr/include" directory also)::

 make INSTALL_HDR_PATH=~/some_sysroot/usr headers_install

Pointing LLC and CLANG is not necessarily if it's installed on HOST and have
in its targets appropriate arm64 arch (usually it has several arches).
Build samples::

 make M=samples/bpf

Or build samples with SYSROOT if some header or library is absent in toolchain,
say libelf, providing address to file system containing headers and libs,
can be RFS of target board::

 make M=samples/bpf SYSROOT=~/some_sysroot