Mdr-C-Tutorial

B.4 程序的解剖：受限的 C ​

在上一节的实战探索中，我们编写的观测程序虽然只有短短十几行，却顺利串联起了内核态字节码编译、代码骨架提炼、用户态装载以及系统调用事件捕获的完整闭环。然而，一旦尝试脱离现成的模板自主拓展逻辑，一系列深植于系统底层与编译原理的疑问便会接踵而至：代码中声明的 SEC("tp/syscalls/sys_enter_write") 编译器属性到底在二进制层面改变了什么，为什么函数本身的名称无足轻重，反而是节区名称起着决定性作用；my_pid 明明被声明为一个平淡无奇的整型对象，身处用户空间的管理程序凭什么能够隔空对其展开读写；为什么在内核态代码中不能像常规 C 语言那样肆意调用 printf 或 malloc；为什么仅仅在局部执行栈上随手开辟一个 1 KB 的缓冲区，编译器便会在构建期毫不留情地报错终止。

这些看似彼此孤立的工程现象，其深层答案全部收敛在同一个物理实体之中：由 .bpf.c 源码经编译器构建产出的 ELF 目标文件。要真正驾驭 eBPF 这项技术，就必须学会透视二进制内部的组织骨架。在这一节中，我们将彻底拆解这个目标二进制文件——首先辨析其内部各个专用节区的职能分工，深入解构 BPF 虚拟机的通用寄存器布局、受限栈内存与定长指令编码规则，随后借助一个仅有一百多行的轻量级 C 语言解释器亲历字节码的执行心智模型，最后系统归纳 C 语言在 BPF 内核沙箱中受到严厉制约的语言特性与规避准则。建立起这种微观层面的硬件与指令认知后，面对复杂的 .bpf.o 二进制文件便能迅速洞悉其意图，在编写内核态代码时亦能从容绕开那些同时引发编译器阻断与内核验证器拒绝的语法陷阱。

本节涉及的所有实战源码均完整收录在 code/系统编程/拓展B_eBPF/B_4_程序的解剖_受限的C/ 目录下，其中的袖珍解释器 mini_vm.c 可以直接使用宿主机上的标准 gcc 编译并脱机运行验证。

1. 一个 .bpf.c 文件由什么组成 ​

首先将用于微观解剖的完整源码呈现在下方。它与前文使用的观测逻辑在功能上完全对齐，但在全局对象的声明上进行了精简，以便我们清晰透视其在目标文件中的投影：

c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

int my_pid = 0;

SEC("tp/syscalls/sys_enter_write")
int handle_write(void *ctx)
{
    __u64 pid_tgid = bpf_get_current_pid_tgid();
    int pid = pid_tgid >> 32;

    if (pid != my_pid) {
        return 0;
    }
    bpf_printk("BPF triggered from PID %d.\n", pid);
    return 0;
}

char LICENSE[] SEC("license") = "Dual BSD/GPL";

这段代码由四个核心维度协同组成：基础头文件的引入、全局状态对象 my_pid、带有 SEC 节属性修饰的核心函数体，以及尾部的开源许可证声明。我们依次剖析它们在最终输出的 ELF 目标文件中分别被塑造为何种形态。

1.1 SEC 宏把函数放进一个以节名命名的段 ​

源码中频繁出现的 SEC 并非 C 语言的原生关键字，而是由 <bpf/bpf_helpers.h> 交付的标准预处理宏。深入审视 libbpf 源码树中对它的底层定义：

c
#if __GNUC__ && !__clang__
#define SEC(name) __attribute__((section(name), used))
#else
#define SEC(name) \
	_Pragma("GCC diagnostic push")					    \
	_Pragma("GCC diagnostic ignored \"-Wignored-attributes\"")	    \
	__attribute__((section(name), used))				    \
	_Pragma("GCC diagnostic pop")					    \
#endif

无论编译器走入哪一个条件分支，其核心载荷都是标准的 GNU 扩展属性：__attribute__((section(name), used))。其中，section 属性强制要求编译器将随后的函数或数据对象安置在 ELF 文件中由 name 字符串显式指定的自定义节区内；而 used 属性则向编译器传达明确的指示：即使该符号在当前单编译单元内从未被任何本地代码显式调用，优化阶段也绝不能将其作为无用死代码强行裁撤。clang 分支中额外嵌套的 _Pragma 机制，纯粹是为了在向特定特殊段注入符号时，主动抑制 clang 容易产生的 -Wignored-attributes 语法噪音。

因此，当预处理器完成对 SEC("tp/syscalls/sys_enter_write") 的展开后，handle_write 函数编译生成的机器指令序列便会被规整存放在名为 tp/syscalls/sys_enter_write 的独立 ELF 代码段中。C 语言层面的函数名本身对底层 libbpf 而言并不具备语法约束力——它仅仅在生成骨架代码时被提取用作结构体成员的唯一访问标识。真正决定该程序被内核划分为哪种执行模型、拥有哪些上下文权限、以及未来应当被挂载在操作系统哪个具体探针上的，完全是节区名称字符串所蕴含的命名契约，相关的具体类型映射规则见 B.10 节。

基于这一机理，在一个单一的 C 源文件中声明多个独立的探针程序，只需要分别书写带有不同 SEC 修饰的函数实体即可。每个函数在经过编译后都会在同一个目标二进制中形成独立的可执行节区：

c
SEC("tp/syscalls/sys_enter_write")
int on_write(void *ctx) { return 0; }

SEC("tp/syscalls/sys_enter_read")
int on_read(void *ctx) { return 0; }

使用 llvm-objdump -h 检查编译产物，节区列表中会并列呈现出 tp/syscalls/sys_enter_write 与 tp/syscalls/sys_enter_read 两个代码段，它们各自占据 0x10 字节（即两条基础虚拟机指令）的存储空间。

1.2 license 节决定能用哪些辅助函数 ​

代码尾部的声明 char LICENSE[] SEC("license") = "Dual BSD/GPL"; 初看之下颇具仪式感，然而 libbpf 与内核验证器会在装载流程中对其进行实打实的语法提取与严谨核验。在 libbpf 初始化目标对象的源码路径中，可以清晰看到依据节名精准查找该符号的逻辑：

c
if (strcmp(name, "license") == 0) {
	err = bpf_object__init_license(obj, data->d_buf, data->d_size);

提取出的许可证字符串会在后续触发 bpf_prog_load 指令时原样递交送入内核。Linux 内核在此处复用了与审查原生可加载内核模块完全对齐的安全准则：一部分深度介入内核核心机制的高阶辅助函数被打上了明确的 GPL 准入标签，仅对开源协议与 GPL 兼容的探针程序开放调用权限。若一个使用了受限辅助函数的程序声明了不兼容的许可证（如 "Proprietary"），内核验证器在装载阶段便会当场中断并驳回请求（具体报错日志见 B.9 节）。诸如 "Dual BSD/GPL"、"GPL" 或 "GPL v2" 等规范声明均能顺利通过审查。

在此处存在一个极其高频的工程语法陷阱：C 语言中的数据符号名绝不能与目标节区名完全重名。因为在标准的 ELF 文件规范中，每一个被创建的节区都会在局部符号表中自动登记一个同名的节区符号，此时如果声明一个同名的全局对象 char license[]，两者在编译期符号表中便会发生激烈的命名冲突，导致 clang 直接拒绝继续构建：

text
$ clang -target bpf -O2 -g -c hello.bpf.c -o hello.bpf.o
error: symbol 'license' is already defined
error: license changed binding to STB_GLOBAL
error: symbol 'license' is already defined
3 errors generated.

因此，业界标准写法要么统一采用大写的符号名 char LICENSE[] SEC("license")，要么采用带下划线的前缀 char _license[] SEC("license")。libbpf 在寻址时仅仅根据字符串匹配目标节区 license，对 C 语言层面的符号名毫无依赖。

1.3 全局对象落在 .bss、.data 或 .rodata ​

在代码顶部声明的 my_pid 表面上看起来不过是一个随处可见的未初始化整型对象，然而在内核态 eBPF 的受限环境中，它的物理驻留机制与常规用户态程序存在本质差异。BPF 程序在内核中并不享有自由读写的传统数据段，libbpf 在解析目标二进制时，会将这些全局对象所在的节区整体打包并向内核申请注册为单元素容量的专用 Array Map 对象。在装载阶段，初始数据会被无损克隆进内核 Map，而在随后的运行时，程序中对这些全局对象的任何解引用，在底层都会被精准翻译为针对该内核 Map 的内存寻址。依据初值与限定修饰符的不同，全局对象分别落入三类特定的数据段：

源码声明与修饰特征对应目标节区初始数据来源与运行时行为
int my_pid = 0;.bss默认规整全零填充，在目标二进制中不占物理文件存储空间
int hit_count = 7;.data直接从编译产物的数据段中提取非零初值并在加载时写入
const volatile int target = 42;.rodata从只读数据段提取初始数据，在内核加载完成后被强置为只读状态

若在一个程序中同时组合这几类声明，使用 llvm-readelf -S 能够清晰捕捉到这三个数据段的并存状态：

text
  [ 5] .bss              NOBITS          0000000000000000 0000a0 000004 00  WA  0   0  4
  [ 6] .data             PROGBITS        0000000000000000 0000a0 000004 00  WA  0   0  4
  [ 7] .rodata           PROGBITS        0000000000000000 0000a4 000004 00  A   0   0  4
  [ 8] license           PROGBITS        0000000000000000 0000a8 000004 00  WA  0   0  1

在上述修饰中，const volatile 中的 volatile 属于不可或缺的核心限定。假若仅仅书写 const int target = 42;，编译器的常量传播优化策略会在汇编阶段直接将数值 42 作为立即数硬编码写死在指令中，从而导致用户态宿主程序在后续即使尝试通过内存映射动态覆写该值也无法撼动内核指令分毫；而追加 volatile 修饰后，编译器便被强制剥夺了常量折叠优化的权利，每次取值都必须严格生成指令从 .rodata 对应的内存映射中现场读取。这一组合机制使得用户态能够在 open 与 load 之间的时间窗口内动态向只读段注入配置参数，其深层运作机制在 B.6 节 会做专项阐释。

全局对象就是单元素数组 map

沉淀在 .bss、.data 与 .rodata 三个专用节区中的所有全局对象，在程序装载期间均由 libbpf 负责在内核中分别转化为单一元素容量的专有 Array Map 实体，并将其虚拟内存平稳映射至用户空间。我们在用户态代码中书写的 skel->bss->my_pid，其本质正是直接读写该内核 Map 空间中偏移为零的物理内存。因此，在内核态探针中对全局对象发起的读写，其底层执行的均是一次确凿的 Map 内存寻址。

1.4 目标文件的节列表 ​

在终端中执行标准编译命令，并利用 llvm-objdump -h 过滤掉复杂的调试辅助段，可以一览目标文件的物理全貌：

bash - hello.bpf.o 的节
text
$ clang -g -O2 -target bpf -mcpu=v3 -D__TARGET_ARCH_x86 -I. -c hello.bpf.c -o hello.bpf.o
$ llvm-objdump -h hello.bpf.o | grep -Ev "debug|addrsig|strtab|symtab|eh_frame"

hello.bpf.o:	file format elf64-bpf

Sections:
Idx Name                            Size     VMA              Type
  0                                 00000000 0000000000000000 
  2 .text                           00000000 0000000000000000 TEXT
  3 tp/syscalls/sys_enter_write     00000068 0000000000000000 TEXT
  4 .reltp/syscalls/sys_enter_write 00000020 0000000000000000 
  5 .bss                            00000004 0000000000000000 BSS
  6 .rodata                         0000001c 0000000000000000 DATA
  7 license                         0000000d 0000000000000000 DATA
 13 .BTF                            00000288 0000000000000000 
 14 .rel.BTF                        00000030 0000000000000000 
 15 .BTF.ext                        000000a0 0000000000000000 
 16 .rel.BTF.ext                    00000070 0000000000000000

我们对其中的重点节区展开逐项呼应：

  • tp/syscalls/sys_enter_write 承载了编译就绪的指令实体，长度为十六进制 0x68（十进制 104 字节）。它包含 11 行汇编指令，其中两条 64 位立即数加载指令各占两个槽位，13 个 8 字节槽位恰好构成了 104 字节的总容量。
  • 紧随其后的 .reltp/syscalls/sys_enter_write 构成了代码段专有的重定位表，容量为 32 字节（对应两条重定位记录），明确指引加载器在装载时刻分别将 my_pid 与只读格式串在内核 Map 中的实际分配地址填补进指令槽中。
  • .bss 长度为 4 字节，恰好容纳一个 32 位整型对象 my_pid；.rodata 长度为 0x1c（即 28 字节），完整封装了长达 27 字符的格式化文本及其末尾的空终止符。
  • license 占据 13 字节，承载着带有终止符的协议文本 "Dual BSD/GPL"。
  • .BTF 与 .BTF.ext 则系统封装了跨平台类型推导、函数行号映射以及 CO-RE 成员访问重定位的全部自省元数据。

需要指出的是，编译参数 -g 在生成上述类型元数据时，会连带产生以 .debug_ 开头的海量传统 DWARF 调试节，它们仅用于辅助反汇编工具呈现源码行号，完全不影响向内核的装载流程。部分工具链在特定编译环境下还会默认吐出 .eh_frame 栈展开段；由于 BPF 运行时严禁复杂的 C++ 异常展开机制，libbpf 在遇到此类不相干节区时会自动打印提示并直接安全跳过，开发者无须为此产生顾虑。通过 bpftool btf dump 工具，我们可以直接从 .BTF 中阅读到这些符号在类型系统中的精准登记，它们构成了整个工具链协同运作的权威依据。

2. BPF 虚拟机 ​

在深入字节码指令之前，首先需要破除一个直觉上的认知误区：内核态 eBPF 代码并不会被 clang 直接编译为宿主机 CPU 原生的 x86-64 或 ARM64 机器码。编译器前端首先将受限 C 代码生成为标准化的 BPF 虚拟机指令序列，由内核验证器在指令图上穷尽所有的安全证明后，再由内核内部内嵌的 JIT 编译器就地翻译为原生硬件指令。因此，我们在反汇编输出中所审视的，实际上是一套由标准委员会（RFC 9669）严格规范的虚拟 RISC 指令集。相较于现代主流的复杂硬件体系架构，这套虚拟机的结构设计极其克制精炼。

2.1 寄存器与栈 ​

BPF 虚拟机在硬件抽象上拥有 11 个 64 位宽度的通用寄存器（编号 R0 到 R10），并且全面支持通过 32 位子寄存器（在汇编表示中记为 w0、w1 至 w10）直接对寄存器的低 32 位展开高效运算。寄存器的功能分工严格遵循专有的调用规约（Calling Convention）：

寄存器编号规约职能与核心生命周期约定
R0承载函数调用的返回值；在探针主逻辑执行完毕退出时，承载当前程序的最终返回值
R1～R5专用于向内核辅助函数、kfunc 或模块内部子程序传递入参，单次调用最多支持五个参数；跨调用不保证内容有效
R6～R9属于调用者保留（Callee-saved）寄存器，在跨越函数调用的整个生命周期内其数值保持不变
R10只读的栈帧基址指针，始终严格锚定在当前函数执行栈的顶端，任何尝试向 R10 写入的指令都会被验证器驳回

在程序被事件唤醒进入入口函数的一瞬间，R1 寄存器被系统预先装填为一个专有的上下文指针（在代码中通常命名为 ctx）。不同的探针挂载类型所交付的上下文内存排布各具特征，相关类型细节将在 B.5 节 展开系统梳理。

单选

BPF 程序开始执行时，R1 里放的是什么？

这次事件对应的上下文指针
调用者的 PID
程序自己的指令地址
map 的地址

BPF 的寄存器与调用约定

BPF 虚拟机配备了 11 个 64 位原生通用寄存器。R0 严格用于收缴函数返回结果；R1 到 R5 用于向被调函数顺序传递入参，其内部数据在函数调用完成后不再受到保护；R6 至 R9 由被调用方负责入栈恢复，其内容在跨越函数调用时得以完整维系；R10 则被固化为只读的局部栈帧基址指针，任何针对 R10 的直接写入指令都会被验证器就地裁决为非法操作。所有参数的传递均强制借由寄存器管道完成，绝不通过栈帧隐式压栈。

除了通用寄存器之外，每一个 BPF 程序（包括其调用的每一个独立子程序）均享有独立受限的栈帧内存，其容量被硬性限制为 512 字节。由于虚拟机栈空间沿高地址向低地址方向单向生长，代码中所有局部数据对象的物理寻址，均被统一表达为基于 R10 基址指针的负向偏移解引用，例如 *(u64 *)(r10 - 0x8)。

BPF 栈的大小

在现代 Linux 内核的执行模型中，单个 BPF 函数的局部栈帧容量上限被严格锁定在 512 字节。任何超出该容量限制的大型复合结构体或缓冲区对象，必须移步至内核 Map 存储通道或环形缓冲区的预留内存空间中分配。栈空间的消耗量在编译构建期由编译器前端直接进行边界推导，一旦单帧理论用量超限，clang 编译器会在构建阶段直接抛出错误并拒绝生成目标文件。

2.2 指令格式 ​

在指令二进制编码上，绝大多数 BPF 指令均保持了极为匀称的 8 字节（64 位）定长格式，其内部精确划分为五个位域：

编码位域物理宽度规范含义与编码职能
opcode8 位操作码，其最低 3 位直接裁决当前指令所属的核心操作大类
dst_reg4 位目的寄存器寻址编号（编码范围 0～10）
src_reg4 位源寄存器寻址编号，或在部分伪指令中用于细分扩展语义
offset16 位16 位带符号整数偏移量，专用于相对条件分支跳转或栈内存基址寻址
imm32 位32 位带符号整型立即数常量

一个 8 字节的二进制切片恰好填补一个标准的虚拟机指令槽位。在整个指令集中，存在一类特殊的宽立即数加载指令，它负责将完整的 64 位大立即数一次性装载进指定寄存器。为了容纳这额外的 32 位高位数据，该指令被设计为连续占用两个指令槽位（总计 16 字节），其高 32 位数据被静置在第二个槽位的 imm 位域中。在反汇编输出中，此类指令通常会被反汇编工具显式标注为 r1 = 0x0 ll，后缀 ll 即代表 64 位长整型（long long）立即数，提示该指令在物理槽位上连续消耗了两行编码空间，这直接导致紧随其后的下一条指令索引编号会跳跃一个数值。

操作码 opcode 的最低 3 位用于划分指令的代数族类：

核心类别标识数值掩码体系职能与操作范围
LD0x0宽立即数加载及 Map 物理地址装填
LDX0x1内存间接加载（Load from memory to register）
ST0x2立即数存入内存（Store immediate to memory）
STX0x3寄存器写入内存（Store register to memory）
ALU0x432 位子寄存器代数算术与逻辑运算
JMP0x564 位寄存器条件跳转、无条件分支及函数调用
JMP320x632 位子寄存器精确条件分支跳转
ALU640x764 位全宽原生算术与逻辑运算

函数调用指令 call 归属于 JMP 操作大类，其操作码固定为 0x85。该指令通过 src_reg 字段的细微取值区分不同的调用形态：当 src_reg 赋值为 0 时，代表依据 imm 中的整数编号调用内核辅助函数；当其取值为 1 时，代表发起针对当前 ELF 目标文件内部其他子程序的相对函数跳转；而当其取值为 2 时，则代表调用现代内核导出的 BTF 强类型函数（kfunc）。

2.3 逐条读 hello 的反汇编 ​

结合反汇编工具输出的汇编清单，我们可以清晰还原指令与源码之间的映射足迹：

text
$ llvm-objdump -dSr hello.bpf.o

0000000000000000 <handle_write>:
;     __u64 pid_tgid = bpf_get_current_pid_tgid();
       0:	85 00 00 00 0e 00 00 00	call 0xe
;     int pid = pid_tgid >> 32;
       1:	77 00 00 00 20 00 00 00	r0 >>= 0x20
;     if (pid != my_pid) {
       2:	18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00	r1 = 0x0 ll
		0000000000000010:  R_BPF_64_64	my_pid
       4:	61 11 00 00 00 00 00 00	r1 = *(u32 *)(r1 + 0x0)
       5:	5e 01 05 00 00 00 00 00	if w1 != w0 goto +0x5 <handle_write+0x58>
;     bpf_printk("BPF triggered from PID %d.\n", pid);
       6:	18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00	r1 = 0x0 ll
		0000000000000030:  R_BPF_64_64	.rodata
       8:	b4 02 00 00 1c 00 00 00	w2 = 0x1c
       9:	bc 03 00 00 00 00 00 00	w3 = w0
      10:	85 00 00 00 06 00 00 00	call 0x6
; }
      11:	b4 00 00 00 00 00 00 00	w0 = 0x0
      12:	95 00 00 00 00 00 00 00	exit

第 0 条指令的原始十六进制字节为 85 00 00 00 0e 00 00 00：操作码 0x85 对应 call 指令；第二字节 0x00 说明 src_reg 赋值为 0，即调用标准辅助函数；末尾四字节的立即数编码了十六进制的 0x0e（十进制 14）。查阅内核官方头文件 bpf_helper_defs.h，14 号辅助函数正是用于获取复合进程凭据的 bpf_get_current_pid_tgid：

c
static __u64 (* const bpf_get_current_pid_tgid)(void) = (void *) 14;

这一声明揭示了一个极为核心的真相：在高级 C 语言代码中表现得如同常规函数指针一般的系统调用，在沉降至字节码层面后，本质上仅仅是一个定长的代号。

第 1 条指令 r0 >>= 0x20 将 R0 中的复合数值逻辑右移 32 位，剥离出高位的进程组 ID（TGID）。

第 2 条指令是占用 16 字节的双宽指令 r1 = 0x0 ll，紧随其后的重定位标签 R_BPF_64_64 my_pid 提示我们，当前处于目标文件中的立即数 0 仅仅是一个占位标记；在后续由用户态 libbpf 发起装载时，该占位符会被原位动态改写为该对象在内核 Map 中的实际分配物理基址。由于它独占了两个槽位，随后的指令编号顺理成章地由 2 直接跳跃至 4。

第 4 条指令 r1 = *(u32 *)(r1 + 0x0) 顺藤摸瓜，从解析出的 Map 基址中提取出 4 字节的整型初值 my_pid。

第 5 条指令 if w1 != w0 goto +0x5 执行高效的 32 位子寄存器等值判定：一旦当前进程号不符，程序便立刻向前相对跃迁 5 条指令，直接跳跃至末尾的标号 11 处顺序退场。

第 6 条至第 10 条指令共同协作完成了 bpf_printk 的宏展开：重定位段首先为 R1 装配指向只读数据段 .rodata 中格式化模板的内存指针，R2 被赋以格式化文本的物理长度 28，R3 接纳需要输出的整数值，随后通过 call 0x6 触发编号为 6 的日志输出辅助函数 bpf_trace_printk。

最后的指令 11 与 12 将返回值寄存器 R0 规整置零，并通过 exit 指令平稳退出虚拟机沙箱，将控制流完整交还宿主内核。

3. 用 C 执行几条 BPF 指令 ​

阅读反汇编虽然能够理清指令流，但虚拟机的概念在脑海中依然容易悬浮于抽象层面。为了在系统编程的层面上亲手触摸这套指令集，我们可以用标准 C 语言编写一个极简的袖珍虚拟机解释器，亲手驱动 clang 为下面这个简单的三元表达式函数所编译出的 BPF 字节码：

c
long calc(long x)
{
    return x > 10 ? x * 3 : x + 1;
}

使用带有 -O2 优化的编译器完成构建后，反汇编输出展示了 6 条干净利落的指令流：

text
$ llvm-objdump -d calc.bpf.o

0000000000000000 <calc>:
       0:	bf 10 00 00 00 00 00 00	r0 = r1
       1:	27 00 00 00 03 00 00 00	r0 *= 0x3
       2:	65 01 02 00 0a 00 00 00	if r1 s> 0xa goto +0x2 <calc+0x28>
       3:	07 01 00 00 01 00 00 00	r1 += 0x1
       4:	bf 10 00 00 00 00 00 00	r0 = r1
       5:	95 00 00 00 00 00 00 00	exit

在工程文件 mini_vm.c 中，我们仅需定义一个基础的指令解码器，并将内存中的字节数组顺序解析为操作码、操作数与偏移量：

c
struct insn {
    uint8_t opcode;
    uint8_t regs;
    int16_t off;
    int32_t imm;
};

static struct insn decode(const uint8_t *p) {
    struct insn in;

    in.opcode = p[0];
    in.regs = p[1];
    in.off = (int16_t)((uint16_t)p[2] | ((uint16_t)p[3] << 8));
    in.imm = (int32_t)((uint32_t)p[4] | ((uint32_t)p[5] << 8) |
                       ((uint32_t)p[6] << 16) | ((uint32_t)p[7] << 24));
    return in;
}

指令的分派循环则根据解析出的 opcode 展开状态机的步进推进，源寄存器与目的寄存器的编号通过简单的位操作从第二字节中剥离：

c
unsigned dst = in.regs & 0x0f;
unsigned src = in.regs >> 4;

switch (in.opcode) {
case OP_MOV_REG:            /* 0xbf */
    regs[dst] = regs[src];
    pc++;
    break;
case OP_MUL_IMM:            /* 0x27 */
    regs[dst] *= (uint64_t)(int64_t)in.imm;
    pc++;
    break;
case OP_JSGT_IMM:           /* 0x65 */
    if ((int64_t)regs[dst] > (int64_t)in.imm) {
        pc = (size_t)((int64_t)pc + 1 + in.off);
    } else {
        pc++;
    }
    break;
case OP_EXIT:               /* 0x95 */
    *result = regs[0];
    return 0;
}

在上述逻辑中，分支跳转指令的相对偏移寻址规则特别值得注意：规范中的 off 偏移量是严格相对于紧随其后的下一条指令进行相对计算的。因此在条件评估为真时，新的程序计数器位置必须按照 pc + 1 + in.off 展开换算。这一设计与主流物理硬件 CPU 的相对跳转处理逻辑完全一脉相承。

我们将反汇编生成的机器码序列逐字节转录为静态数组载荷，并在测试程序中将同一组测试用例分别投递给宿主机本地函数与我们的小型解释器展开交叉验证：

bash - mini_vm
text
$ gcc -std=c17 -Wall -Wextra -O2 mini_vm.c -o mini_vm
$ ./mini_vm
x =   0   BPF:   1   C:   1
x =   1   BPF:   2   C:   2
x =   5   BPF:   6   C:   6
x =  10   BPF:  11   C:  11
x =  11   BPF:  33   C:  33
x =  20   BPF:  60   C:  60
x = 100   BPF: 300   C: 300

x = 20 的执行过程：
   0: opcode 0xbf dst r0 src r1 off +0 imm 0
      r0 = 20  r1 = 20
   1: opcode 0x27 dst r0 src r0 off +0 imm 3
      r0 = 60  r1 = 20
   2: opcode 0x65 dst r1 src r0 off +2 imm 10
      r0 = 60  r1 = 20
   5: opcode 0x95 dst r0 src r0 off +0 imm 0
      r0 = 60  r1 = 20

  结果 60

以入参 x = 20 为例跟踪状态机的轨迹：代码首先在 R0 中保留入参并在乘法指令后计算出 60；随后的条件跳转指令确认 20 大于 10，相对跳转即刻生效，程序直接跳过随后的加法分支跃迁至末尾的 exit 退出，顺利产出 60。这段脱机的轻量实现虽然没有接入内核复杂的安全验证器与 JIT 翻译器，却让 BPF 指令的流转与求值过程变得触手可及。

4. C 语言的限制 ​

编写内核态 .bpf.c 代码虽然沿用了 C 语言的词法与类型规范，但其目标运行环境绝非一个随心所欲的普通用户态进程。在这里，不存在标准 C 运行时库（libc）的辅助支撑，底层硬件指令集彻底剔除了浮点运算单元，每一个执行帧的局部栈空间被严密封死在 512 字节以内，且任何野指针解引用都会招致内核验证器的直接阻断。这些看似严酷的语法束缚在本质上源于同一个系统安全哲学：这段代码未来将要在最高特权级的操作系统内核中、在极度脆弱的任意上下文（乃至硬件中断上下文中）就地飞速运转，而在它获准执行之前，其全部状态转移必须能够在数学上被静态证明为绝对安全收敛。

4.1 没有 libc，也没有浮点 ​

在内核态代码中，常规系统编程中习以为常的 printf、malloc、free、strcpy 等标准库函数全量缺席。若需要向外派发日志，必须使用内核专属的 bpf_printk 或 bpf_trace_printk；若需要安全探测未知内存空间，必须调用 bpf_probe_read_* 系列辅助函数；若需要读取内核或用户空间的字符串，则必须经由 bpf_probe_read_kernel_str 等专用安全通道完成。

针对内存块的高速擦写，编译器原生内置的 __builtin_memcpy 与 __builtin_memset 是被允许调用的，但前提是操作的数据字节长度在编译期必须是一个可完全推导的整型常量——唯有如此，clang 才能在前端优化阶段将其就地展开为数条紧凑的高速寄存器内存写入指令，彻底规避真实的函数调用产生：

c
char buf[16];
int n = bpf_get_smp_processor_id();

__builtin_memset(buf, 0, sizeof(buf));
buf[n & 15] = 1;
return buf[0] + n;

审视其反汇编可以发现，对 16 字节缓冲区的清零被编译器直接原地生成为两条基于 R10 的 8 字节双字写栈指令：

text
       1:	b7 01 00 00 00 00 00 00	r1 = 0x0
       2:	7b 1a f0 ff 00 00 00 00	*(u64 *)(r10 - 0x10) = r1
       3:	7b 1a f8 ff 00 00 00 00	*(u64 *)(r10 - 0x8) = r1

在生成的指令流中完全不存在任何 call 跳转。然而，倘若数据复制或初始化的长度依赖运行期的动态参数，编译器前端便无法进行静态内联展开，构建会当场失败：

c
int f(void *ctx, int n) {
    char buf[16];

    __builtin_memset(buf, 0, n);
    return buf[0];
}
text
$ clang -target bpf -O2 -g -c memset_rt.c -o memset_rt.o
memset_rt.c:4:5: error: A call to built-in function 'memset' is not supported.
    4 |     __builtin_memset(buf, 0, n);
      |     ^
1 error generated.

浮点运算的限制则更为底层而坚固。BPF 虚拟机的指令规范中自始至终未曾纳入任何浮点算术操作码，高级语言中针对 float 或 double 的算术运算必须依赖编译器注入庞大的纯软件模拟函数（如 __adddf3 或 __fixdfsi），而这些底层软浮点运行库在轻量级的 BPF 目标后端中根本不存在：

text
$ clang -target bpf -O2 -g -c float.bpf.c -o float.bpf.o
float.bpf.c:10:11: error: A call to built-in function '__adddf3' is not supported.
   10 |     x = x * 2.0;
      |           ^
float.bpf.c:11:12: error: A call to built-in function '__fixdfsi' is not supported.
   11 |     return (int)x;
      |            ^
2 errors generated.

在操作系统内核的世界里，无论纳秒时钟、吞吐频次还是百分比指标，均采用规整的整数进行量化。若业务逻辑不可避免地需要表达小数比例，行业通行做法是在代码中显式选定基准量纲（例如采用纳秒对齐秒、或者用基数 10000 换算基点比率）展开定点数代数计算。

4.2 栈只有 512 字节 ​

BPF 程序单个执行帧的局部栈空间上限为严苛的 512 字节，这从根本上杜绝了在局部栈上声明庞大缓冲区的可能。如果我们在函数内部声明了一个 1 KB 的字符数组并对其发起逐字节写入，clang 编译器会在分析栈帧布局时立刻终止编译并给出清晰的处置指引：

c
SEC("tp/syscalls/sys_enter_write")
int big_stack(void *ctx)
{
    char buf[1024];
    int i;

    for (i = 0; i < 1024; i++) {
        buf[i] = i;
    }
    bpf_printk("last byte %d\n", buf[1023]);
    return 0;
}
bash - 栈超限
text
$ clang -g -O2 -target bpf -mcpu=v3 -I. -c stack_too_big.bpf.c -o stack_too_big.bpf.o
stack_too_big.bpf.c:5:5: error: Looks like the BPF stack limit is exceeded. Please move large on stack variables into BPF per-cpu array map. For non-kernel uses, the stack can be increased using -mllvm -bpf-stack-size.
    5 | int big_stack(void *ctx)
      |     ^
stack_too_big.bpf.c:5:5: note: could not determine the original source location for stack_too_big.bpf.c:0:0
1 error generated.

编译器所给出的诊断提示精准指明了工业界的应对策略：将超出栈容量的大型数据对象移入专属的 Per-CPU Array Map 中分配（详见 B.6 节），或者直接向环形缓冲区申请预留内存空间。

在工程实践中还存在一个有趣的编译优化细节：如果在源码中声明了庞大的局部数组，但后续代码中仅使用了单一常数偏移（例如仅访问 buf[0]），在开启 -O2 优化时，编译器的寄存器分配器可能会将该孤立数据直接捕获并压入寄存器，彻底优化抹除整个物理栈数组的分配，导致代码意外“编译通过”。因此，切莫将能够生成目标文件简单等同于栈安全，养成利用 llvm-objdump -d 审查实际栈指针偏移量的习惯，是编写高质量内核态程序的重要功底。

单选

下列写法中，哪一种在编译期就会失败？

在函数里声明 char buf[1024] 并逐个写入
在 64 位寄存器上做整数乘法
在 kprobe 程序的入口读 ctx 参数
在循环里累加一个整数 64 次

4.3 不能递归，调用深度有限 ​

现代 eBPF 运行时虽然原生支持 BPF 函数之间的子程序调用（BPF-to-BPF Calls），然而为了确保内核调度安全，整个虚拟机调用栈的最大嵌套深度被严格限定在 8 层以内。任何形式的递归调用都会在函数拓扑图上构成闭环，由于其理论栈深度无法在离线状态下求得上界，内核验证器在装载期间会当场驳回：

text
$ llvm-objdump -dr rec3.bpf.o
0000000000000000 <is_even>:
       0:	b4 00 00 00 01 00 00 00	w0 = 0x1
       1:	16 01 02 00 00 00 00 00	if w1 == 0x0 goto +0x2 <is_even+0x20>
       2:	04 01 00 00 ff ff ff ff	w1 += -0x1
       3:	85 10 00 00 01 00 00 00	call 0x1
       4:	95 00 00 00 00 00 00 00	exit

指令 call 0x1 中的 src_reg 为 1，代表对目标文件内局部子程序的相对调用。一旦多个子函数之间存在相互递归或自调用，控制流图（CFG）中便会出现无界循环链，验证器在无法证明调用深度绝对收敛的情况下必须拒绝放行。在面对需要反复迭代递推的算法逻辑时，必须将其规整重写为具有明确物理边界的循环体，切莫依赖函数自调用。

4.4 循环必须能证明会结束 ​

自 Linux 5.3 内核合入有界循环审查算法以来，循环结构在 eBPF 中正式获得了合法地位，但其使用的先决条件是验证器必须能够在有限的状态状态空间内推演出明确的终止上界。形如 for (int i = 0; i < 64; i++) 这种边界完全由编译期常量锁定的循环，验证器能够直接通过路径展开完成全状态证明，因而是最为稳妥的编写范式。若循环的跃迁边界来源于运行期的外部输入，则必须在代码中显式通过条件分支将取值区间收拢在狭小的范围内，或者改用现代内核提供的 bpf_loop 辅助设施与开放编码迭代器（Open-coded Iterators）。

在底层指令层面，-O2 优化策略通常会尽可能将能够确定结果的静态循环在编译阶段彻底打平。若一段累加循环的求值能够在编译期被常量推演彻底消化，反汇编中甚至只剩下一条直接将常数写入 R0 的传送指令与一条退出指令：

c
int sum = 0;

for (int i = 0; i < 64; i++) {
    sum += i;
}
return sum;

而当循环体内部包含依赖外部运行时的动态采样时，真正的循环控制指令才会在字节码中如实显现：

text
$ llvm-objdump -d looptest.bpf.o
0000000000000000 <bounded>:
       0:	b4 06 00 00 00 00 00 00	w6 = 0x0
       1:	85 00 00 00 08 00 00 00	call 0x8
       2:	b4 02 00 00 00 00 00 00	w2 = 0x0
       3:	bc 61 00 00 00 00 00 00	w1 = w6
       4:	54 01 00 00 01 00 00 00	w1 &= 0x1
       5:	84 01 00 00 00 00 00 00	w1 = -w1
       6:	5c 01 00 00 00 00 00 00	w1 &= w0
       7:	0c 21 00 00 00 00 00 00	w1 += w2
       8:	04 06 00 00 01 00 00 00	w6 += 0x1
       9:	bc 12 00 00 00 00 00 00	w2 = w1
      10:	16 06 01 00 40 00 00 00	if w6 == 0x40 goto +0x1 <bounded+0x60>
      11:	05 00 f7 ff 00 00 00 00	goto -0x9 <bounded+0x18>
      12:	bc 10 00 00 00 00 00 00	w0 = w1
      13:	95 00 00 00 00 00 00 00	exit

汇编中的指令 10 与 11 精准构成了循环的回边与跳出分支：计数子寄存器 w6 每次递增并与 0x40（十进制 64）展开判定，不等则向前跃迁回指令 3 重新执行。指令中明文编码的硬上限，构成了内核验证器认定该循环绝对具有有限边界的关键凭据。

4.5 指针不能随意解引用 ​

在 eBPF 程序中，仅有执行栈局部内存、程序入参交付的特定合法上下文区域、以及从内核 Map 寻址成功且经过非空指针审查的内存块，才被允许使用常规的 C 语言解引用语法直接读取。除此之外，任何指向内核内部核心结构体或用户空间平面的任意地址指针，都绝对禁止直接发起 *ptr 式的裸内存解引用。所有此类跨边界读取，必须严格借由专属的系统辅助函数完成：读取内核空间必须发起 bpf_probe_read_kernel，读取用户态空间则必须发起 bpf_probe_read_user。

这一防线的成因完全植根于内存安全与缺页异常保护机制：由于内核探针可能挂载在不允许发生页面置换或阻塞睡眠的热点关键路径上，直接解引用一个由于换页、野指针或非对齐造成的非法地址，极易引发内核级致命异常。借助辅助函数，内核能够在专有的缺页异常保护机制下安全尝试读取，一旦读取受阻则安全返回错误码，从而坚决捍卫操作系统的稳定性。现代 CO-RE 体系所交付的 BPF_CORE_READ 系列宏，本质上是在编译期为我们自动化编织了一串带有安全重定位的辅助函数链条。

4.6 为什么常写 static __always_inline ​

在审视成熟的 eBPF 开源项目头文件时，大量的辅助小函数均被清一色地冠以 static __always_inline 修饰符：

c
#define __always_inline inline __attribute__((always_inline))
#define __noinline __attribute__((noinline))

为微型函数附加 __always_inline 属性，会指示编译器在代码生成阶段无条件将其指令内联展开到每一个被调用的物理点，在二进制汇编中消除一切函数调用跳转指令；反之，若附加 __noinline，该函数便会被隔离在独立的 .text 代码段中，所有的调用点都会退化为一条带有重定位标签的相对跳转指令：

text
$ llvm-objdump -dr inl.bpf.o

Disassembly of section .text:

0000000000000000 <thrice>:
       0:	bc 10 00 00 00 00 00 00	w0 = w1
       1:	24 00 00 00 03 00 00 00	w0 *= 0x3
       2:	95 00 00 00 00 00 00 00	exit

Disassembly of section tp/syscalls/sys_enter_write:

0000000000000000 <f>:
       0:	85 00 00 00 08 00 00 00	call 0x8
       1:	bc 06 00 00 00 00 00 00	w6 = w0
       2:	64 06 00 00 01 00 00 00	w6 <<= 0x1
       3:	bc 01 00 00 00 00 00 00	w1 = w0
       4:	85 10 00 00 ff ff ff ff	call -0x1
		0000000000000020:  R_BPF_64_32	.text
       5:	0c 06 00 00 00 00 00 00	w6 += w0
       6:	bc 60 00 00 00 00 00 00	w0 = w6
       7:	95 00 00 00 00 00 00 00	exit

选择无条件内联的核心考量完全服务于内核验证器的审查特征。在现代验证器的推演模型中，虽然支持跨函数调用的独立静态证明，但一个独立的子函数必须在完全脱离具体调用上下文的最一般性假定下完成自洽证明，这往往对参数校验施加了极为苛刻的约束；而一旦通过内联将其彻底打平为单帧直线代码，验证器便能够完整继承外层主逻辑已经证明成立的寄存器取值范围与指针合法性，从而大幅提升复杂程序通过验证的概率。其唯一的代价是过度的代码展开会导致目标二进制体积膨胀，需要开发者根据逻辑规模适度权衡。

5. 旧资料里的限制 ​

随着 Linux 内核与 eBPF 运行时机制的快速演进，许多在早期内核（如 Linux 4.x 时代）被列为绝对红线的技术禁区，在现代体系结构与工具链的协同演进下，早已被逐步打破或重新定义。网络社区与早期技术博客中沉淀的大量文章，往往遗留着诸如“BPF 程序绝对不能包含循环”、“BPF 程序完全无法声明和使用全局对象”等断言。如果开发者未经甄别地采信这些早期认知，往往会在现代程序设计中引入许多繁复且不必要的规避逻辑。本节将这些演进历程与现行现状作一次系统性的对照梳理，其中所标注的内核版本号仅用于还原技术演变的时间节点：

旧说法今天的情况何时放宽
不能有循环有界循环可以，验证器会展开检查内核 5.3
不能有全局对象.bss、.data、.rodata 里的全局对象正常使用内核 5.2（libbpf 同时支持）
不能有常量字符串字符串放进 .rodata，加载时重定位内核 5.2
一切都要内联，不能有函数调用BPF 到 BPF 的调用可用，深度上限 8内核 4.16、LLVM 6.0
程序最多 4096 条指令特权程序的上限提高到 100 万条指令；非特权程序仍是 4096 条内核 5.2
栈只有 512 字节仍然如此未变
不能用浮点仍然如此未变

在技术实践中，当审视各类外部资料中关于“BPF 无法支持某项特性”的技术断言时，关注其成文年代往往是排除陈旧认知最高效的依据。在 2019 年（约对应 Linux 内核 5.2 发布）之前成文的材料中，上表中前五项关于循环、全局对象与指令配额的限制确实是当时的技术现状；而随着现代 BTF、有界循环静态验证算法以及内存映射机制的落地，这些桎梏均已得到了系统性的解除。唯独 512 字节的固定调用栈容量与浮点运算的绝对缺失，自 BPF 诞生起便作为内核执行安全与执行上下文切换开销的终极防线，不曾发生任何松动。

此外，还有若干无论置于哪个发展阶段都不准确的常见误区，在开发实践中尤为需要厘清：

常见说法实际情况
一个 BPF 程序只能有一个入口，多个程序要分文件一个 .bpf.c 里可以写任意多个带 SEC 的函数，各自是一个独立的程序
SEC 后面的字符串只是注释它是标准的 ELF 节名，libbpf 严格依赖它判断程序挂载类型与附加语义
许可证随便写，只影响法律问题不写或声明不兼容的协议，在调用 GPL 导出的内核辅助函数时会被验证器直接驳回
单选

在这一章的环境下（内核 6.12、clang 19、libbpf 1.5），下列哪些限制仍然有效？

栈只有 512 字节
不能有全局对象
循环必须能证明会结束
不能用浮点运算
不能调用 libc 函数

判断一份资料的年代

在研读外部文档或开源代码时，可以通过几个鲜明的技术特征快速判断其时代脉络：如果源码中仍在使用旧式的 struct bpf_map_def 结构体来声明 Map、过度依赖 bcc 的字符串内嵌 C 代码机制，抑或是缺失了现代规范的 SEC("...") 宏声明，通常表明该资料成文于 2019 年之前，属于 CO-RE 与现代 libbpf 架构普及前的早期技术探索。

6. 编译选项 ​

在前面的环境配置章节中，我们已经接触过针对内核态 BPF 程序的基础编译命令。这里我们将逐项剖析每一个关键参数的底层用意，理解它们如何协助编译器跨越架构鸿沟：

bash - 内核态程序的编译
text
$ clang -g -O2 -target bpf -mcpu=v3 -D__TARGET_ARCH_x86 -I. -c hello.bpf.c -o hello.bpf.o
  • -target bpf：明确指定目标体系结构为 BPF。如果不加此选项，Clang 将默认遵循当前宿主机环境（如 x86-64 或 AArch64）生成机器码，其产出的目标文件完全无法被 libbpf 解析并投递给内核验证器。
  • -g：指示编译器在生成目标文件时附带完整的 DWARF 调试信息与 BTF（BPF Type Format）类型数据。没有 BTF，后续在 B.8 中赖以实现跨内核运行的 CO-RE 重定位便完全无从展开，诸如 bpftool gen skeleton 等代码生成工具也将无法从二进制文件中提取出程序骨架所需的数据布局结构。回顾前文中展示的 ELF 节区列表，缺失 -g 选项的目标文件中将彻底不见 .BTF 与 .BTF.ext 的身影。
  • -O2：在 BPF 的构建体系中，优化级别从来不是可有可无的性能锦上添花，而是程序能否顺利通过内核静态验证的生死门槛。在 -O0（未优化）模式下，Clang 采取极其朴素的直接翻译策略，会将几乎每一个局部对象都频繁地在仅有 512 字节的狭小栈空间上进行推入与读回，导致总指令数量呈倍数膨胀并迅速耗尽验证器的复杂度上限。更为关键的是间接函数调用：在 C 语言中通过函数指针触发的调用，在 -O2 优化下编译器能够将其精确折叠并直接内联展开；而在 -O0 下则会保留为原生的间接调用指令 callx（操作码 0x8d），现行 Linux 内核验证器并不支持这条指令，会直接判定加载失败。
  • -mcpu=v3：显式指定 BPF 处理器的指令集架构版本。在 Clang 的演进过程中，默认指令集版本在不同发行版之间可能在 v1 与 v3 之间变动。显式将其锚定为 v3，能够促使编译器稳定生成包含 32 位子寄存器操作指令的最优字节码，确保跨平台构建与调试输出的高度确定性。
  • -D__TARGET_ARCH_x86：向头文件环境（特别是 bpf_tracing.h）显式声明当前的宿主机物理架构。诸如 BPF_KPROBE 这类宏机制需要依靠该宏来准确解析宿主机的上下文结构体（如 struct pt_regs）的成员排布与寄存器映射。若遗漏该定义，预处理器将直接中断编译并抛出架构未指定的明确错误。

指令集架构版本 -mcpu 的选取所带来的差异是具体且可量化的。以经典的 hello 跟踪程序为例，分别采用 v1 与 v3 进行编译，其生成的字节码在底层指令呈现上存在着显著分野：

bash - -mcpu=v1 与 -mcpu=v3
text
$ clang -target bpf -mcpu=v1 -O2 -g -c hello.bpf.c -o hello_v1.o
$ clang -target bpf -mcpu=v3 -O2 -g -c hello.bpf.c -o hello.bpf.o
$ diff <(llvm-objdump -d hello_v1.o | tail -n +3) \
       <(llvm-objdump -d hello.bpf.o | tail -n +3)
9c9
<        5:	5d 01 05 00 00 00 00 00	if r1 != r0 goto +0x5 <handle_write+0x58>
---
>        5:	5e 01 05 00 00 00 00 00	if w1 != w0 goto +0x5 <handle_write+0x58>
11,12c11,12
<        8:	b7 02 00 00 1c 00 00 00	r2 = 0x1c
<        9:	bf 03 00 00 00 00 00 00	r3 = r0
---
>        8:	b4 02 00 00 1c 00 00 00	w2 = 0x1c
>        9:	bc 03 00 00 00 00 00 00	w3 = w0
14c14
<       11:	b7 00 00 00 00 00 00 00	r0 = 0x0
---
>       11:	b4 00 00 00 00 00 00 00	w0 = 0x0

在 v1 指令集中，所有的比较与赋值均依托于全尺寸的 64 位通用寄存器展开（如 if r1 != r0、r2 = 0x1c、r0 = 0x0）；而在引入了 32 位子寄存器机制的 v3 指令集中，编译器能够精准使用 w 系列子寄存器指令（如 if w1 != w0、w2 = 0x1c、w0 = 0x0），其操作码也随之发生切换。这种转变的实际收益在于：针对 32 位整数的操作不再需要全字长的冗余运算，内核 JIT 编译器在将其翻译为现代 x86 或 ARM 机器码时能够产出更为紧凑短小的机器指令。

当然，缺乏 32 位专有指令的 v1 架构并非无法处理常规的 int 类型运算。当遇到 32 位逻辑时，v1 会被迫通过额外的 64 位移位操作来进行等效模拟，其直接代价是指令数量的显著膨胀。通过一个简单的整数计算函数，我们可以清晰观察到这一开销差异：

text
$ clang -target bpf -mcpu=v1 -O2 -c calc_int.bpf.c -o ci_v1.o
$ llvm-objdump -d ci_v1.o
0000000000000000 <calc>:
       0:	bf 10 00 00 00 00 00 00	r0 = r1
       1:	27 00 00 00 03 00 00 00	r0 *= 0x3
       2:	bf 12 00 00 00 00 00 00	r2 = r1
       3:	67 02 00 00 20 00 00 00	r2 <<= 0x20
       4:	c7 02 00 00 20 00 00 00	r2 s>>= 0x20
       5:	65 02 02 00 0a 00 00 00	if r2 s> 0xa goto +0x2 <calc+0x40>
       6:	07 01 00 00 01 00 00 00	r1 += 0x1
       7:	bf 10 00 00 00 00 00 00	r0 = r1
       8:	95 00 00 00 00 00 00 00	exit
$ clang -target bpf -mcpu=v3 -O2 -c calc_int.bpf.c -o ci_v3.o
$ llvm-objdump -d ci_v3.o
0000000000000000 <calc>:
       0:	bc 10 00 00 00 00 00 00	w0 = w1
       1:	24 00 00 00 03 00 00 00	w0 *= 0x3
       2:	66 01 02 00 0a 00 00 00	if w1 s> 0xa goto +0x2 <calc+0x28>
       3:	04 01 00 00 01 00 00 00	w1 += 0x1
       4:	bc 10 00 00 00 00 00 00	w0 = w1
       5:	95 00 00 00 00 00 00 00	exit

在 v1 生成的 9 条指令中，第 2 条至第 4 条指令纯粹是在利用 64 位寄存器的左移与算术右移来人工模拟 32 位有符号整数的符号位扩展；而在 v3 下，仅需 6 条指令即可利落完成，直接对 w1 与立即数 0xa 进行有符号判定。倘若函数参数原生即为 64 位宽的 long，两者生成的字节码将完全一致。因此，在日常编译配置中始终指定 -mcpu=v3 是一种零风险且高收益的工程惯例：它对宽整数绝无性能折损，却能为常规整型消除可观的冗余指令。

而优化选项从 -O0 跳跃至 -O2 所带来的质变，则更为惊人。以同一个计算函数在不同优化级别下的反汇编输出为参照：

❌ -O0
text
0000000000000000 <calc>:
       0:	7b 1a f8 ff 00 00 00 00	*(u64 *)(r10 - 0x8) = r1
       1:	79 a1 f8 ff 00 00 00 00	r1 = *(u64 *)(r10 - 0x8)
       2:	c5 01 05 00 0b 00 00 00	if r1 s< 0xb goto +0x5 <calc+0x40>
       3:	05 00 00 00 00 00 00 00	goto +0x0 <calc+0x20>
       4:	79 a1 f8 ff 00 00 00 00	r1 = *(u64 *)(r10 - 0x8)
       5:	27 01 00 00 03 00 00 00	r1 *= 0x3
       6:	7b 1a f0 ff 00 00 00 00	*(u64 *)(r10 - 0x10) = r1
       7:	05 00 04 00 00 00 00 00	goto +0x4 <calc+0x60>
       8:	79 a1 f8 ff 00 00 00 00	r1 = *(u64 *)(r10 - 0x8)
       9:	07 01 00 00 01 00 00 00	r1 += 0x1
      10:	7b 1a f0 ff 00 00 00 00	*(u64 *)(r10 - 0x10) = r1
      11:	05 00 00 00 00 00 00 00	goto +0x0 <calc+0x60>
      12:	79 a0 f0 ff 00 00 00 00	r0 = *(u64 *)(r10 - 0x10)
      13:	95 00 00 00 00 00 00 00	exit
✅ -O2
text
0000000000000000 <calc>:
       0:	bf 10 00 00 00 00 00 00	r0 = r1
       1:	27 00 00 00 03 00 00 00	r0 *= 0x3
       2:	65 01 02 00 0a 00 00 00	if r1 s> 0xa goto +0x2 <calc+0x28>
       3:	07 01 00 00 01 00 00 00	r1 += 0x1
       4:	bf 10 00 00 00 00 00 00	r0 = r1
       5:	95 00 00 00 00 00 00 00	exit

在 -O0 的版本中，全篇充斥着 14 条笨拙的指令：入参必须率先写入基于 r10 寻址的栈空间，每次参与运算前再从栈中重新读回，中间计算结果再次写回栈中，最后才转存至 R0。这种反复的栈内存读写多达七次；而在经过 -O2 优化后，所有操作均纯粹在寄存器之间完成，仅需 6 条指令且无任何栈访存开销。由于验证器需要为每一条执行路径推演所有寄存器与栈插槽的状态集合，-O0 代码所引入的繁琐状态分支会使验证器的分析负担呈几何级数加剧。

另外值得一提的是，在 Windows 宿主环境下若使用 Zig 工具链内置的 Clang 进行代码编译检查，往往需要额外追加 -fno-sanitize=all 参数：这是因为 Zig 驱动默认启用了若干未定义行为检查运行时，而裸机 BPF 目标并不具备与之配套的错误报告运行库。标准 Linux 发行版所提供的独立 Clang 则无须此顾虑。

7. 写错了会怎样 ​

在实际编写与构建受限 C 语言程序时，由于不慎触碰体系限制而引发的错误往往会在不同生命周期阶段浮现。以下汇总了各类典型编码失误在编译期所触发的明确报错特征：

写法结果
char license[] SEC("license")error: symbol 'license' is already defined，符号名与节名相同
栈上开辟 1 KB 数组并实际使用error: Looks like the BPF stack limit is exceeded
用 double 做加减乘error: A call to built-in function '__adddf3' is not supported
调用 printf、malloc 等 libc 函数编译能过，留下未定义的符号；bpftool gen skeleton 报 failed to find BTF for extern 'printf'
用 BPF_KPROBE 却没定义 __TARGET_ARCH_x86error: Must specify a BPF target arch via __TARGET_ARCH_xxx
未启用优化时写了函数指针调用字节码里出现 callx（0x8d），内核验证器不认

在分析上述错误时，浮点运算与标准库调用的断裂阶段差异尤为值得深思：浮点运算是在 Clang 代码生成阶段即刻宣告失败，因为 BPF 后端根本不具备任何能够支持 __adddf3 辅助例程的底层实现；而对 libc 库函数的调用，在编译期却能顺畅通过——编译器仅在目标文件中保留了一个未解析的外部符号引用，直到构建流程行进至骨架打包或 libbpf 尝试解析 BTF 外部符号时，问题才骤然暴露。这种延迟暴露的特征往往更容易令初学者感到困惑。

而关于间接调用 callx 的产生机理同样耐人寻味。当我们在 C 代码中使用函数指针时，未优化的 -O0 模式会忠实地生成一条间接调用指令：

text
      22:	79 a2 e8 ff 00 00 00 00	r2 = *(u64 *)(r10 - 0x18)
      23:	79 a1 f8 ff 00 00 00 00	r1 = *(u64 *)(r10 - 0x8)
      24:	8d 02 00 00 00 00 00 00	callx r2

操作码 0x8d 代表寄存器间接跳转，此时跳转的目标函数地址完全依赖运行期寄存器 r2 的动态取值。而在开启了 -O2 优化的情况下，Clang 能够对控制流进行常量传播与死代码消除，精确判定出候选函数的实际归属并将其直接内联展开，从而从根本上消除了 callx 的生成。换言之，未优化代码能否通过编译，表面上取决于函数指针的存在与否，但由于 C 语言生态中函数指针与回调机制极具普遍性，在工程实践中“必须开启编译器优化”已成为保障 BPF 可执行性的金科玉律。

当然，还有一大类更为深刻的逻辑失误属于编译器完全无能为力的范畴：目标文件结构规范、符号完备，但在加载至内核的一瞬间，却被内核验证器无情拦截。诸如 Map 查找后未作空指针校验便直接解引用、或者环形缓冲区空间预留（reserve）后在某条分支路径上遗漏了提交（commit）操作等。这些深层次的安全审查逻辑属于内核验证器的专属领地，关于验证器报错日志的解读与修正策略，我们将在 B.9 中专门展开深入剖析。

8. 习题 ​

8.1 巩固 ​

#46401
⚡2⏳1

下面这段程序编译后，count、limit、table 三个对象分别落在哪个节？用 llvm-readelf -S 验证你的答案。

c
int count = 0;
const volatile int limit = 100;
int table[4] = {1, 2, 3, 4};

SEC("tp/syscalls/sys_enter_write")
int f(void *ctx) { return count + limit + table[0]; }

再回答一个问题：为什么 limit 必须写成 const volatile，只写 const 会有什么后果？

#46402
⚡2⏳2

下面是从 hello.bpf.o 里截出来的四条指令：

text
       0:	85 00 00 00 0e 00 00 00	call 0xe
       2:	18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00	r1 = 0x0 ll
       4:	61 11 00 00 00 00 00 00	r1 = *(u32 *)(r1 + 0x0)
       5:	5e 01 05 00 00 00 00 00	if w1 != w0 goto +0x5

(1) 第 0 条调用的是哪个辅助函数？根据是什么？ (2) 为什么编号从 2 直接跳到 4？ (3) 第 5 条跳转生效时，下一条执行的指令编号是多少？ (4) 61 11 这两个字节里的两个 11 分别是什么含义？

8.2 编程 ​

#46403
⚡3⏳3

code/系统编程/拓展B_eBPF/B_4_程序的解剖_受限的C/stack_too_big.bpf.c 里有两个错误：一个是栈超限，另一个在 license 那一行。分别改掉它们，让文件通过编译，并说明两个错误分别在编译的哪个阶段被发现。

改好之后用 llvm-objdump -d 确认：大数组确实不在栈上了。提示：可以把数组改成每 CPU 数组 map（B.6 有写法），也可以先把它缩小到 512 字节以内看现象。

#46404
⚡3⏳3

写一个 twoprog.bpf.c，满足以下要求，编译后用 llvm-objdump -h 和 llvm-readelf -S 检查：

  • 一个文件里放两个程序，分别挂在 tp/syscalls/sys_enter_write 和 tp/syscalls/sys_enter_read 上；
  • 一个初始化为非零的 int 全局对象，落在 .data；
  • 一个 const volatile int 全局对象，落在 .rodata；
  • license 用 "GPL"。

验收标准：节列表里同时出现两个 tp/ 开头的节、.data 和 .rodata，且 .data 的大小与你声明的对象一致。再用 bpftool btf dump file twoprog.bpf.o 找到两个 FUNC 记录和两个 DATASEC 记录，把输出贴出来。

#46405
⚡4⏳3

取本页的 calc.bpf.c，分别用 -mcpu=v1 和 -mcpu=v3 编译，把两份反汇编都保存下来做 diff：

(1) 逐条说明差异出在哪里。两版的指令条数一样，那么 v3 省在了什么地方？ (2) 把函数改成 int calc(int x)，再对比一次。这次两版的指令条数分别是多少？ (3) 用 -mcpu=v1 编译的字节码，能在只支持 v1 的内核上加载；反过来，用 -mcpu=v3 编译、在只支持 v1 的内核上加载，会怎样？第二问可以结合 llc -march bpf -mcpu=help 的输出和 -mcpu=probe 的用途回答。

#46406
⚡5⏳4

本页的 mini_vm.c 只能跑 -O2 生成的 calc 字节码。把它扩展到能跑 clang -O0 -c calc.bpf.c 生成的那一份，需要补上四类指令：

  • 0x7b：把 64 位寄存器写到 r10 减偏移的栈位置（STX，双字）；
  • 0x79：从栈位置读回 64 位寄存器（LDX，双字）；
  • 0xc5：有符号小于立即数时跳转（JMP32，if r1 s< 0xb）；
  • 0x05：无条件跳转（JA）。

自己用 clang -O0 -c calc.bpf.c 生成字节码，用 llvm-objdump -d 抄成字节数组，然后验证七组输入的运行结果与 -O2 版本一致。

要求：栈用 uint8_t stack[512] 表示，R10 初始化为 512，访存按小端解释。做完之后回答：为什么 -O0 的字节码里会出现 r10 - 0x8 这样的地址，而 -O2 版本一条都没有？

8.3 综合与挑战 ​

#46407
⚡6⏳5选做

给 mini_vm.c 加一个最小的静态检查器，在真正执行之前拒绝明显非法的字节码。至少检查这四项，每项都要给出可读的报错信息：

(1) opcode 是否在支持的集合里； (2) 每条指令的 dst_reg 和 src_reg 是否都不大于 10； (3) 所有跳转的目标是否落在指令范围内； (4) 最后一条指令是不是 exit，以及从第 0 条出发是否所有路径都能到达 exit。

用三类输入测试：正常的 calc 字节码、故意把跳转偏移改大的字节码、把最后一条 exit 改成 w0 = 0 的字节码。第三类需要你实现一个可达性检查，可以用简单的深度优先搜索。

做完之后读一段真实验证器的日志（B.9 里有），对比你的检查器和它在检查深度上的差别。

9. 参考资料 ​