LWN：使用 Eurydice 将 Rust 编译为可读的 C 代码

关注

转载最新推荐文章于 2026-11-08 19:00:00 发布 57 阅读 AI 写同款· GEO 优化 ›

＜数据集＞咖啡叶片病害识别＜目标检测＞ YOLO与VOC格式的咖啡叶片病害识别数据集，适用于YOLO系列、Faster Rcnn、SSD等模型训练，类别：Cercospora、Miner、Phoma、Rust，图片数量1744。文件中包含图片、txt标签、指定类别信息的yaml文件、xml标签，已将图片和txt标签划分为训练集、验证集和测试集，可直接用于YOLOv5、YOLOv6、YOLOv7、YOLOv8、YOLOv9、YOLOv10、YOLOv11、YOLOv12、YOLOv13、YOLOv26等YOLO系列算法的训练。阅读详情

Daroc Alden
Gemini translation
原文链接：https://lwn.net/Articles/1055211/

几年前，编译 Rust 代码的唯一方法是使用以 LLVM 为后端 (backend) 的 rustc 编译器。此后，包括 Mutabah 的 Rust 编译器 (mrustc)、GCC 的 Rust 支持 (gccrs)、rust_codegen_gcc 以及 Cranelift 在内的数个项目在实现 Rust 编译器多样化方面取得了巨大进展。最近的一个此类项目 Eurydice 提出了一个更宏大的目标：将 Rust 代码转换为整洁的 C 代码。这在高度可靠 (high-assurance) 的软件中尤其有用，因为现有的验证和合规工具通常要求使用 C 语言。在这些工具更新到支持 Rust 之前，Eurydice 可以为这些项目提供更平滑的过渡，并为那些拥有 C 编译器但没有可用 Rust 编译器的环境提供一个跳板。例如，Eurydice 已被用于将一些后量子密码学 (post-quantum-cryptography) 例程从 Rust 编译为 C。

Eurydice 始于 2023 年，包含一些基于 MIT 许可证 (license) 的代码和一些基于 Apache-2.0 许可证的代码。它是 Aeneas 项目的一部分，该项目致力于开发多种与将形式化验证 (formal verification) 工具应用于 Rust 代码相关的工具。Aeneas 的各个项目由受雇于 Inria（法国国家信息与自动化研究所）和微软的一群人维护，但也接受外部贡献。

Eurydice 遵循与许多编译器相同的通用结构：获取 Rust 程序，将其转换为中间表示 (Intermediate Representation, IR)，通过一系列处理阶段 (pass) 修改 IR，然后将其输出为低级语言（在本例中为 C）代码。Eurydice 最活跃的贡献者 Jonathan Protzenko 曾发布过一篇博文，解释了该项目的方法。然而，与其他编译器不同的是，Eurydice 关注的是在保留代码整体结构的同时，移除 Rust 中存在而 C 中不存在的构造。例如，考虑这个 Rust 函数，它使用最大公约数 (greatest common denominator) 计算两个数的最小公倍数 (least common multiple)：

●●●
..fn.gcd(a: u64, b: u64).-> u64.{
......if.b ==.0.{
..........a
......}.else.{
..........gcd(b, a%b)
......}
..}

..fn.lcm(a: u64, b: u64).-> u64.{
......(a *.b)./.gcd(a, b)
..}

以下是 Eurydice 如何将这些函数编译为 C 的：

●●●
..uint64_t.example_gcd(uint64_t.a,.uint64_t.b)
..{
....uint64_t.uu____0;
....if.(b ==.0ULL)
......{
........uu____0.=.a;
......}
....else
......{
........uu____0.=.example_gcd(b,.a %.b);
......}
....return.uu____0;
..}

..uint64_t.example_lcm(uint64_t.a,.uint64_t.b)
..{
....uint64_t.uu____0.=.a *.b;
....return.uu____0 /.example_gcd(a,.b);
..}

这段 C 代码是否算作“可读”可能取决于个人口味。然而，它确实保留了代码的结构。通过在必要时添加额外的临时变量（如 example_lcm 函数中的 uu____0）来定义顺序，它甚至保留了原始代码的求值顺序。（Rust 保证如果乘法溢出并导致恐慌 (panic)，这会发生在调用 example_gcd 产生的任何副作用之前，但 C 只有在乘法在单独的语句中执行时才能保证这一点。）相比之下，使用 rustc 编译相同的函数会产生一对充满位操作 (bit-twiddling) 的纠缠循环——这对于机器码输出很合适，但可读性要差得多。

当然，并非所有的 Rust 程序都能在 C 中得到忠实的呈现。例如，使用迭代器 (iterator) 而非范围 (range) 的 for 循环需要被编译为 while 循环，并调用 Eurydice 的一些支持代码来管理迭代器的状态。更重要的是，C 没有泛型 (generics) 的概念，因此 Rust 代码在转换过程中需要进行单态化 (monomorphized)。这可能导致一个函数的多个不同实现，它们仅在类型上有所不同——通常，更惯用的 C 方法是使用宏 (macro) 或 void * 参数。

动态大小类型 (dynamically sized types) 的实现也带来了一些挑战。在 Rust 中，可以定义一个结构体，其中一个字段没有固定大小——类似于 C 中的柔性数组项 (flexible array member)：

●●●
..struct.DynamicallySized<U: ?Sized>.{
......header: usize,
......my_data: U, // 编译器在这里不知道 U 的大小
..}

但如果该结构体是泛型的，并且类型的某个泛型使用者为柔性大小字段提供了一个已知大小的类型，编译器就可以利用这些知识在适当的地方省略边界检查 (bounds check)。

●●●
..let.foo: DynamicallySized<[u8;.4]>.=....;
..// 由于已知数组大小为 4，因此不会发出边界检查：
..let.bar.=.foo.my_data[2];

这种分离（代码的某些部分可能知道类型的大小，而某些部分可能不知道）是一个需要在 C 中保留的重要语义细节，因为它与形式化验证的可能性存在交互。如果 Eurydice 在所有地方都将 DynamicallySized 编译为使用柔性数组项，那么对 C 代码的分析可能会指出在 Rust 中并不需要的“缺失”边界检查。相反，如果 Eurydice 添加了额外的边界检查，它就需要制造出原始 Rust 代码中未出现且本应完全不被使用的额外错误路径。

因此，Eurydice 会生成两种不同的类型：一种是带有柔性数组项的动态大小类型版本，另一种是带有已知长度数组项的版本。在这两种表示之间转换在运行时是不执行任何操作的 (no-op)，但它在技术上违反了 C 语言的严格别名 (strict-aliasing) 规则。因此 Protzenko 建议在编译 Eurydice 生成的代码时使用 -fno-strict-aliasing。