eBPF程序为何需要多轮Pass才能生成JIT编译代码？

你之前认为的eBPF指令到原生机器码一对一映射的认知是不准确的：JIT过程中跳转偏移、常量加载、寻址方式的最优短编码选择，强依赖代码段中所有指令的实际内存布局，第一轮生成的代码全是保守预留的最长编码占位，后续每一轮都会根据上一轮算出的实际地址，把长指令替换成功能完全等价的短指令，所以镜像体积会逐轮收缩，直到没有可替换的短编码为止。

对应bpf_jit_comp.c的实际逻辑与示例 #

x86-64指令集是变长指令集，同一条语义的指令可以有多种长度不同的编码，这是体积能收缩的核心基础，多轮Pass的逻辑完全围绕短编码替换展开：

• 首轮Pass（初始编译）：所有涉及地址引用、常量加载的指令，全部选择最长的合法编码做占位，完全不考虑实际取值范围：
  • 跳转指令统一预留5字节的近跳转编码（32位相对偏移，寻址范围±2GB），不使用2字节的短跳转（8位相对偏移，仅支持±127字节范围）
  • 常量加载统一使用10字节的movabs $imm64, %reg编码，不考虑常量实际位宽
  • 内存寻址统一使用带32位偏移的长编码，不使用8位偏移的短寻址编码
    这一轮生成的镜像是体积最大的保守版本，所有指令的位置、偏移都按最坏情况预留。
• 后续迭代Pass：拿着上一轮生成的完整指令布局、各指令的实际偏移值，逐指令检查是否可以替换为更短的等价编码：
  • 若某条跳转指令的实际目标偏移落在±127字节范围内，就把5字节近跳转替换为2字节短跳转，单条指令省3字节
  • 若加载的常量实际小于2^32，就把10字节movabs替换为7字节的movl $imm32, %reg（x86-64下写入32位寄存器会自动零扩展到64位，语义完全一致）；如果常量小于2^8，还能替换为更短的5字节编码，单条最多省5字节
  • 若栈访问、上下文访问的实际偏移落在±127字节范围内，就把带32位偏移的长寻址编码替换为8位偏移的短寻址编码，单条省2-3字节
• 迭代终止逻辑：每完成一轮替换，所有后续指令的内存地址都会往前移动，可能让原本不满足短编码范围的其他指令突然满足替换条件，因此必须反复迭代，直到某一轮跑完没有任何指令可以再替换为短编码、镜像体积和上一轮完全一致，才会停止生成最终镜像。

举个可对应到源码逻辑的极简例子：
假设eBPF程序包含一条if r0 != 0 goto +3的分支指令：

1. 第一轮Pass：不知道后续指令实际长度，给分支预留5字节近跳转，算得整段代码总长度132字节
2. 第二轮Pass：计算得分支目标距离当前指令仅92字节，符合短跳转范围，把5字节分支替换为2字节短分支，省出3字节，后续所有指令地址前移3位，整段代码总长度变为129字节
3. 第三轮Pass：重新计算所有指令的偏移，发现原本距离短跳转范围差2字节的另一条分支，现在因为整体地址前移，刚好落在±127范围内，又替换成2字节短跳转，再省3字节，总长度变为126字节
4. 第四轮Pass：遍历所有指令，确认没有可替换的短编码，总长度和第三轮一致，迭代终止。

这种多轮收敛的逻辑是变长指令集JIT的常规设计，不是eBPF独有的特性——本质是因为短编码替换本身会改变代码布局，无法一次遍历就算出所有短编码的合法条件，必须迭代到稳定状态才能得到体积最小、执行效率最高的机器码。

内容的提问来源于stack exchange，提问作者Nicholas