LWN：使用GCC编译生成BPF程序

点击上方蓝色“Linux News搬运工”关注我们~

Compiling to BPF with GCC

By Jonathan Corbet

---

LPC

自从在kernel里加上eBPF (extended BPF) 之后，诞生了很多各式各样的应用场景。不过还是只有很少人真正写过BPF代码。因为目前BPF代码就有点像其他那些汇编级语言，挺难用的。写BPF program是可以用C语言的，LLVM编译器可以把C语言编译成BPF program。不过，在2019 Linux Plumbers Conference上的Toolchains microconference中，Jose Marchesi指出，LLVM不久后会成立一个公司，所以他就在GCC编译器里也加上了BPF back-end支持。

Marchesi自己定位是一个编译器工作者，而不是BPF trace专家。他介绍说GCC的支持经过了3个阶段。首先在toolchain里添加BPF的最基本的支持，包括让GCC能支持一个新的bpf-unknown-none的target，以及binutils在5月份就支持了BPF；在会议之前，GCC的代码库里合入了BPF支持。

从现在起，GCC可以编译生成BPF program了，不过还有一个障碍：生成的BPF program必须要能通过kernel里的BPF verifier的审查。也就是说编译生成的program需要指令顺序符合规范。Marchesi认为应该还是能够做到的，随着kernel verifier也在变得更加聪明（例如支持有限次数的循环了），那么GCC生成代码这边的难度也会更加小一些。

最后一个阶段还在进行中，就是需要为开发者们创造一些新的工具。例如BPF的simulator，用来在user space运行，可以通过GDB来调试BPF program。在他看来，BPF就像是某种类型的嵌入式平台一样，需要针对这种平台创建各种工具才能让普通开发者正常进行开发。

他认为BPF virtual machine就像是一种特殊类型的平台，表面上看起来很普通，其实不然。这个虚拟机需要依赖kernel提供的各种helper功能。他打算把这些helper功能重新在GCC内部也实现出来，这种方式就跟LLVM所用的不一样了。他认为这种方案更加稳定，不过会需要长久维护这些helper功能。要想维护好这些helper，还是很有难度的，因为每个kernel版本都不一样。这就意味着GCC需要使用一个新的参数（例如-mkernel=）来指定kernel版本号，就像是-mcpu用来指定CPU一样。这样的话，编译器就能抓出来那些在目标版本kernel中并不支持的helper功能了。

Peter Zijlstra在这里插了一个问题，是否也支持各种企业版的kernel版本。这些发行版里面，kernel可能包含了很多backport patch，所以base版本号其实并不能精确反映这个信息。Marchesi的回答是他现在还只支持mainline kernel的版本号。H. Peter Anvin建议可以把这些helper信息放到kernel的UAPI头文件里面去，这样在编译时就能直接拿到了。Nick Alcock则建议说，可以利用参数上指定的kernel版本号来读取某个描述文件，从而确定支持哪些helper。还有一位听众则认为把helper函数builtin到GCC里不是个好方法。如果用户拿到新的kernel，他们就没法编译BPF来利用新增的helper功能了。

Marchesi继续介绍，他希望能对C语言支持的越完整越好。不过这个很困难，因为BPF program的限制很多。他也在建议创建一个BPF的试验性版本，称之为xBPF，这个版本的限制更加少。例如xBPF可以支持更大的stack frame，也可以有indirect call instruction（间接调用指令）。参数可以直接通过stack传递，从而增加了函数可以使用的参数数量。他还希望能支持带符号数的除法。

为什么需要创建一个xBPF呢？这里主要的吸引力来自于可以执行更详尽的编译器测试。目前来说，他得关闭几百个GCC test，因为BPF根本没法运行这些测试。此外xBPF还能让调试更加容易，能容易生成backtrace。还会让去除verifier的各种限制的试验过程更加容易一些。并且，xBPF会可以使用各种ELF链接功能。他很想让LLVM也能支持xBPF。

接下来，他会希望能有一个verifer运行在user space。BPF verifier的代码是相当复杂精致，能有一个user space版本的话，就可以更容易的发现问题。他并不打算重新开发一个verifier，而是希望能有什么办法直接利用kernel的verifier代码。

最后Marchesi问道，BPF ABI是什么？目前，它只能根据LLVM生成什么以及kernel接受什么来决定。我们需要对BPF建立文档描述清楚这个ABI，只有这样才能让多种实现版本（无论是LLVM还是GCC生成）都可以互相协作。随着BPF使用越来越广泛，他很希望能投身其中，为GNU toolchain做更多贡献。

[Your editor thanks the Linux Foundation, LWN's travel sponsor, for supporting travel to this event.]

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～