eBPF动手实践系列二：构建基于纯C语言的eBPF项目
The following article is from 阿里灵杰 Author 闻茂泉
01
千里之行，始于足下
02
eBPF开发的基础环境准备
2.1 rpm包基础环境初始化
在centos、fedora和anolis等发行版环境，需要安装一些编译过程的基础包、编译工具包、库依赖包和头文件依赖包等。具体安装步骤如下：
$ yum install git make rsync # 基础包$ yum install clang llvm elfutils-libelf-devel # 编译工具和依赖库包$ yum install kernel-headers-$(uname -r) kernel-devel-$(uname -r) # 头文件依赖包2.2 deb包基础环境初始化
在ubuntu、debian等发行版环境，需要安装一些编译过程的基础包、编译工具包、库依赖包和头文件依赖包等。具体安装步骤如下：
$ apt-get update # 更新apt源信息$ apt install git make rsync # 基础包 $ apt install clang llvm libelf-dev # 编译工具和依赖库包$ apt install linux-libc-dev linux-headers-$(uname -r) # 头文件依赖包💡 小贴士：rpm包和deb包的差异
依赖的rpm包和deb包的包名比较容易搞混，centos环境的rpm包kernel-headers对应的是ubuntu环境的deb包linux-libc-dev， rpm包kernel-devel对应的是deb包linux-headers。可以通过如下2个命令分别查看rpm包和deb包的内容，进而识别包的异同：rpm -ql kernel-devel-$(uname -r) # rpm包执行此命令
dpkg -L linux-headers-$(uname -r) # deb包执行此命令
03
构建基于纯C语言的eBPF项目
3.1 纯C语言编译
在eBPF基础环境的准备完成之后，就可以开始进行纯C语言的eBPF项目的搭建。这里我们仍然选择使用centos8u+4.18内核为例来说明构建过程。首次构建项目环境还需要依赖一次内核源码。下载内核源码，我们推荐使用阿里云的镜像网站。
$ wget https://mirrors.aliyun.com/linux-kernel/v4.x/linux-4.18.tar.gz$ tar -zxvf linux-4.18.tar.gz获取ebpf_purec_newbie git项目的代码。并且通过其中的initialize.sh脚本，初始化eBPF项目。initialize.sh脚本需要两个参数。
参数1用于指定内核源码的路径，
参数2用于指定新初始化的ebpf项目的目录，参数2可省略，省略后将默认设置为 /tmp/ebpf_project。
$ git clone https://github.com/alibaba/sreworks-ext.git -b master$ cd sreworks-ext/demos/ebpf_purec_newbie$ ./initialize.sh ~/linux-4.18 /tmp/ebpf_project$ cd /tmp/ebpf_project$ make$ sudo ./trace_outputrecv 662097 events per sec3.2 一些特殊情况的处理
3.2.1 函数test_attr__open定义相关问题
在5.4到5.9版本的内核编译时，可能会遇到undefined reference to `test_attr__open'相关的问题。解决办法是打开Makefile中的HAVE_ATTR_TEST宏。具体可在编译前，执行如下命令修改Makefile文件。
$ sed -i '/DHAVE_ATTR_TEST/{ s/^#//;}' /tmp/ebpf_project/Makefile3.2.2 执行ebpf程序报Operation not permitted错误
在一些版本的内核，运行编译完的ebpf程序trace_output时，会报Operation not permitted错误。解决办法是调大进程的MEMLOCK资源限制。具体可在trace_output_user.c的main函数中snprintf函数之前，添加如下代码。
+ struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};+ setrlimit(RLIMIT_MEMLOCK, &r); snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);同时还需要添加相关头文件。
#include <sys/resource.h>04
ebpf_project初始化脚本解析
在ebpf_purec_newbie代码项目下，只包含3个文件：initialize.sh、Makefile和Makefile.libbpf。
$ ls ebpf_purec_newbie/initialize.sh Makefile Makefile.libbpf其中initialize.sh脚本是生成新的eBPF项目ebpf_project的脚本。下面介绍ebpf_project项目各个目录或者文件的来源。
ebpf_project/tools目录的内容主要是来自于内核源码目录linux-4.18/tools。
ebpf_project/helpers目录的内容主要是来自于内核源码中samples/bpf/和tools/testing/selftests/bpf/两个目录中的一些helper类型的文件。内核源码中将这些helper类型的文件和样例文件混杂在一起，给初学者造成一些学习上的混乱。有鉴于此，我们统一集中到一个helpers目录下。
trace_output_kern.c和trace_output_user.c这两个是ebpf样例文件，来自于内核源码的samples/bpf/目录。这两个文件是成对出现的，需重点关注，后文我们还会提到。
ebpf_project/Makefile文件来自于项目ebpf_purec_newbie/Makefile文件。
ebpf_project/tools/lib/bpf/Makefile文件来自于项目ebpf_purec_newbie/Makefile.libbpf文件。
05
ebpf_project项目Makefile解析
5.1 Makefile解析过程提取
通常情况下了解Makefile的解析过程，需要阅读Makefile源码，不过本文提出另外一种分析思路，那就是巧妙地使用make命令的--debug选项参数，SHELL环境变量参数，以及makefile语法中的warning控制函数。依靠这些技巧，我们可以轻松地对makefile的详细解析过程进行提取。
$ cd /tmp/ebpf_project/$ make clean$ cd tools/lib/bpf/$ make --debug=v,m SHELL="bash -x" > libbpf_make.log 2>&1$ cd /tmp/ebpf_project/$ make --debug=v,m SHELL="bash -x" > main_make.log 2>&1分别获取了生成libbpf.a静态库的日志文件libbpf_make.log，以及生成ebpf可执行程序的主日志文件main_make.log。
5.2 生成libbpf.a静态库的Makefile解析
通过对'Considering target file'内容的过滤，可以了解到tools/lib/bpf/Makefile展开过程。通过这样的一层一层的构建过程，最终将tools/lib/bpf/目录下的几个文件bpf.c、btf.c、libbpf.c和nlattr.c构建了libbpf.a静态库文件。
$ cat libbpf_make.log | grep 'Considering target file'
Considering target file `all'. Considering target file `libbpf-in.o'. Considering target file `precheck'. Considering target file `force'. Considering target file `elfdep'. Considering target file `bpfdep'. Considering target file `btf.o'. Considering target file `btf.c'. Considering target file `libbpf.o'. Considering target file `libbpf.c'. Considering target file `nlattr.o'. Considering target file `nlattr.c'. Considering target file `bpf.o'. Considering target file `bpf.c'. Considering target file `libbpf_errno.o'. Considering target file `libbpf_errno.c'. Considering target file `str_error.o'. Considering target file `str_error.c'.以libbpf.o target为例，可以看到具体一个target的完整解析过程。通常，在“Must remake target ”后会有“Invoking recipe from Makefile”，再之后便是我们最关心的实际执行的命令（recipe）部分。
Considering target file `libbpf.o'.File `libbpf.o' does not exist.
Considering target file `libbpf.c'.
Finished prerequisites of target file `libbpf.c'.
No need to remake target `libbpf.c'.
Finished prerequisites of target file `libbpf.o'.
Must remake target `libbpf.o'.
Invoking recipe from Makefile:143 to update target `libbpf.o'.
gcc '-DBUILD_STR(s)=#s' -o libbpf.o -c libbpf.c
Successfully remade target file `libbpf.o'.
最终在all这个target下，通过ar rcs libbpf.a libbpf-in.o这个命令（recipe）生成了libbpf.a静态库文件。
5.3 项目主Makefile解析
这里同样也可以通过对'Considering target file'内容的过滤，了解到主Makefile的展开过程。每一个target部分，也会有与其对应的"Invoking recipe from Makefile"部分，以及实际执行的命令（recipe）部分。
$ cat main_make.log | grep 'Considering target file'
Considering target file `all'. Considering target file `trace_output'. Considering target file `bpf_prog'. Considering target file `verify_target_bpf'. Considering target file `verify_cmds'. Considering target file `clang'. Considering target file `llc'. Considering target file `trace_output_kern.o'. Considering target file `trace_output_kern.c'. Considering target file `tools/lib/bpf/libbpf.a'. Considering target file `helpers/trace_helpers.o'. Considering target file `helpers/trace_helpers.c'. Considering target file `helpers/bpf_load.o'. Considering target file `helpers/bpf_load.c'. Considering target file `trace_output_user.o'. Considering target file `trace_output_user.c'.以上一层一层的构建步骤，产出目标文件主要是2个：trace_output_kern.o和trace_output。
其中trace_output_kern.o目标文件主要由样例文件trace_output_kern.c编译产生。
而trace_output目标文件主要由样例文件trace_output_user.c，两个helper文件bpf_load.c和trace_helpers.c，以及上一步的产物libbpf.a静态库编译产生。这里的target libbpf.a的部分的recipe命令，是最终触发libbpf Makefile的make构建过程的代码。
06
关键编译命令的编译参数解析
6.1 内核态bpf程序(trace_output_kern.o)编译参数解析
编译trace_output_kern.o命令的选项参数中，如下8个选项参数依赖的文件路径正好是kernel-devel这个rpm包的内容，这也是我们脱离内核源码编译的一个地方。
-I/lib/modules/4.18.0-348.7.1.el8_5.x86_64/build/arch/x86/include -I/lib/modules/4.18.0-348.7.1.el8_5.x86_64/build/arch/x86/include/generated -I/lib/modules/4.18.0-348.7.1.el8_5.x86_64/build/include -I/lib/modules/4.18.0-348.7.1.el8_5.x86_64/build/arch/x86/include/uapi -I/lib/modules/4.18.0-348.7.1.el8_5.x86_64/build/arch/x86/include/generated/uapi -I/lib/modules/4.18.0-348.7.1.el8_5.x86_64/build/include/uapi -I/lib/modules/4.18.0-348.7.1.el8_5.x86_64/build/include/generated/uapi -include /lib/modules/4.18.0-348.7.1.el8_5.x86_64/build//include/linux/kconfig.hbpf_helpers.h是编译内核态bpf程序所依赖的关键的helper文件。随着内核版本的变化，此文件放置的位置和内核源码中的样例程序引用的方式也发生了变化。在低版本中，随意的放到了tools/testing/selftests/bpf路径，引用方式为#include "bpf_helpers.h"。而在高版本内核中，放置的相对规范一些，bpf_helpers.h文件被放置到了tools/lib/bpf路径，引用方式也自然改为了#include <bpf/bpf_helpers.h>。同时，在我们这里的头文件include路径里，也有细微差别。低版本内核，我们将bpf_helpers.h文件规范性的拷贝到到了新项目的helpers目录，相应的是“-I./helpers”选项参数起作用。而在高版本内核是”-I./tools/lib/”选项参数起了作用。
较高版本的clang编译器，在添加-g选项参数后，会编译出带.BTF段的目标文件。但较低版本的clang却没有这个功能，无法直接编译出带BTF段的目标文件。即使这样，仍然可以通过pahole -J命令，将目标文件中的DWARF-2信息，转换出BTF段信息。 较低版本的clang编译器，不支持'asm goto'语法结构。解决办法是通过“-include asm_goto_workaround.h”选项参数，给内核态bpf文件主动添加asm_goto_workaround.h头文件，绕过这个问题。
6.2 用户态加载程序(trace_output)编译参数解析
编译trace_output的gcc命令中，gcc不用显式的指定系统头文件列表，gcc会默认到系统默认的头文件列表中查找头文件。使用如下命令可以显示系统默认的头文件包含哪些。其中/usr/include文件路径正好是kernel-header这个rpm包的内容所在的目录，这里也是我们脱离内核源码编译的第二个地方。
$ gcc -xc /dev/null -E -Wp,-v 2>&1 | sed -n 's,^ ,,p'
/usr/lib/gcc/x86_64-redhat-linux/8/include/usr/local/include/usr/includelibbpf.h头文件是编译ebpf用户态程序时，必不可少的头文件依赖。随着内核版本的变化，在内核源码的样例程序中引用的方式也发生了细微变化。在较低版本内核源码样例中，引用方式是“#include <libbpf.h>”，在较高版本内核源码样例中，引用方式是“#include <bpf/libbpf.h>”。与此同时libbpf.h在内核源码中的放置位置并没有变化，一直都是tools/lib/bpf/libbpf.h。配合这种引用方式的变化的，是头文件搜索路径的调整，低版本内核源码样例头文件搜索路径是“-I./tools/lib/bpf/”，高版本内核源码样例头文件搜索路径是“-I./tools/lib/”。
07
进一步探索
SREWorks数智运维工程群(钉钉群号：35853026)
跟踪诊断技术 SIG 开发者&用户群（钉钉群号：33304007）
更多推荐
点击「阅读原文」查看SREWorks开源地址！