[Rust] Rust for Linux kernel

[heiher]

Working tree: https://github.com/heiher/linux/commits/loongarch-rust

Built-in

[    0.000000] Linux version 6.7.0-rc1-next-20231117+ (hev@lvm) (clang version 18.0.0 (https://github.com/llvm/llvm-project 0c97a37d8faa8179f103b6a34b70270375caf761), LLD 18.0.0) #2 SMP PREEMPT Sat Nov 18 23:33:44 CST 2023
[    0.000000] 64-bit Loongson Processor probed (LA464 Core)
...
[    0.639473] rust_minimal: Rust minimal sample (init)
[    0.639621] rust_minimal: Am I built-in? true
[    0.639865] rust_print: Rust printing macros sample (init)
[    0.639942] rust_print: Emergency message (level 0) without args
[    0.640031] rust_print: Alert message (level 1) without args
[    0.640113] rust_print: Critical message (level 2) without args
[    0.640197] rust_print: Error message (level 3) without args
[    0.640282] rust_print: Warning message (level 4) without args
[    0.640361] rust_print: Notice message (level 5) without args
[    0.640437] rust_print: Info message (level 6) without args
[    0.640555] rust_print: A line that is continued without args
[    0.640669] rust_print: Emergency message (level 0) with args
[    0.640751] rust_print: Alert message (level 1) with args
[    0.640826] rust_print: Critical message (level 2) with args
[    0.640906] rust_print: Error message (level 3) with args
[    0.640988] rust_print: Warning message (level 4) with args
[    0.641066] rust_print: Notice message (level 5) with args
[    0.641146] rust_print: Info message (level 6) with args
[    0.641218] rust_print: A line that is continued with args
[    0.641346] rust_print: 1
[    0.641492] rust_print: "hello, world"
[    0.641710] rust_print: [samples/rust/rust_print.rs:34] c = "hello, world"
[    0.641905] rust_print: "hello, world"

Module

[root@vm ~]# cat /proc/version 
Linux version 6.7.0-rc1-next-20231117+ (hev@lvm) (clang version 18.0.0 (https://github.com/llvm/llvm-project 0c97a37d8faa8179f103b6a34b70270375caf761), LLD 18.0.0) #1 SMP PREEMPT Sat Nov 18 23:28:32 CST 2023
[root@vm ~]# insmod rust_minimal.ko 
[   31.499253] rust_minimal: Rust minimal sample (init)
[   31.499440] rust_minimal: Am I built-in? false
[root@vm ~]# insmod rust_print.ko 
[   35.983847] rust_print: Rust printing macros sample (init)
[   35.983947] rust_print: Emergency message (level 0) without args
[   35.984007] rust_print: Alert message (level 1) without args
[   35.984057] rust_print: Critical message (level 2) without args
[   35.984118] rust_print: Error message (level 3) without args
[   35.984170] rust_print: Warning message (level 4) without args
[   35.984230] rust_print: Notice message (level 5) without args
[   35.984288] rust_print: Info message (level 6) without args
[   35.984345] rust_print: A line that is continued without args
[   35.984643] rust_print: Emergency message (level 0) with args
[   35.984703] rust_print: Alert message (level 1) with args
[   35.984757] rust_print: Critical message (level 2) with args
[   35.984813] rust_print: Error message (level 3) with args
[   35.984868] rust_print: Warning message (level 4) with args
[   35.984921] rust_print: Notice message (level 5) with args
[   35.984975] rust_print: Info message (level 6) with args
[   35.985028] rust_print: A line that is continued with args
[   35.985134] rust_print: 1
[   35.985211] rust_print: "hello, world"
[   35.985420] rust_print: [samples/rust/rust_print.rs:34] c = "hello, world"

[heiher]

为了能兼容上游的Rust 1.73.0编译器，Rust模块目前使用了PIC模式。与no-PIC+no-direct-access-external-data相比，直接用PIC模式都可能有哪些缺点？ @xry111

[xry111]

为了能兼容上游的Rust 1.73.0编译器，Rust模块目前使用了PIC模式。与no-PIC+no-direct-access-external-data相比，直接用PIC模式都可能有哪些缺点？ @xry111

首先我们要区分 PIC 的两种概念，在教科书中 PIC 是指 position-independent code，就是这段代码加载到哪里都能执行。通过 PC-relative 寻址或者 GOT 都能实现 PIC。目前无论是 GCC 还是 Clang，在 LoongArch 上都是无条件生成此种定义下的 PIC。即使用了 -fno-PIC 生成出来也是 PIC，因为 -fno-PIC 只是说可以不生成 PIC，不是说必须不生成 PIC (总不能强行加个“如果加载地址变化就执行 break 指令”罢)。

编译器生成代码时，如果要访问其他 TU 的符号，无法知道那个 TU 是否跨越了共享库边界，所以会保守地假设它可能跨越共享库边界。这种寻址要么用运行时 text relocation，这是上个世纪 32 位 x86 的做法，目前由于有安全隐患已经在用户态禁用；要么用 copy relocation，目前已经被 Maskray 批倒，估计以后也要禁用；要么就用 GOT。这和是不是 PIC 无关，别的架构上如果把 copy relocation 关掉，生成出来的非位置无关代码也会用 GOT 访问外部 TU 中的符号。

而在 GCC 和 Clang 的命令行选项中，-fPIC 是指为共享库生成代码。这时首先要满足一般 PIC 的条件，因为共享库可能被加载到不同的地址 (古早的 x86 共享库有强行做运行时 text relocation 的替代方法，但我们之前说了这个东西已被禁用)。但是此时对于同一 TU 中具有默认 visibility 的数据符号也会使用 GOT 而非 PC-relative 寻址。例如

lib.c:

int x = 42;
int t (void) { return x; }

exe.c:

int x = 114514;
extern int printf (const char *, ...);
extern int t (void);
int main (void) { printf("%d\n", t ()); }

编译并运行：

cc lib.c -fPIC -shared -o lib.so
cc exec. lib.so -Wl,-rpath .
./a.out

会输出 114514 而不是 42。 因为 SysV ABI 规定此时无论是 lib.c 中还是 exe.c 中访问 x 的时候都必须从 GOT 取 x 的地址。

这个规则是共享库起源时某种试图让共享库更“像”静态库的尝试，现在回头看的结论是这属于邯郸学步，既学得不像又使得编译器在 -fPIC 时不得不禁止很多优化。然而一个规则一旦订立，大家就会开始用它干各种事情，然后规则就很难改了。

那么为什么 -fPIC 不仅表示生成 PIC，还表示要生成用于共享库的代码呢？因为 PIC 最早就是用于共享库的。后来大家发现 PIC 还能干别的 (至少可以把主程序也编译成 PIC 然后做一个 ASLR)，于是表示生成 PIC 但不需要用于共享库的开关变成了 -fPIE。如果重做一套体系的话，-fPIE 应该改叫 -fPIC，而 -fPIC 应该改叫 -fso 或者 -fdylib 或者什么东西。

在 LLVM 中我不是很确定 relocation-model={pic,static} 的定义。按定义我们可以让 relocation-model=static 隐含 direct-extern-access 吗？如果不可以那可能就得让 Rustc 把 direct-extern-access 开关给我们暴露出一个 -C 选项了。

[heiher]

@xry111 感谢~

除了宏观规则上的约束，这个问题确实也需要结合后端ISA及具体实现来看，LoongArch(相比于MIPS)指令系统增强了PC-Rel的能力，这一定程度上已经缩小了no-PIC和PIC代码生成的差异。所以我的想法就是我们先在现有的可配置参数上评估下能不能找出近似的组合，可能不能完全等价，但只要开销不是很明显或许也是一种方法。这可以减少架构特定的修改和增大编译器版本的适用范围。

[heiher]

rust-lang/rust#118053

[heiher]

Rust Null Block Driver: https://github.com/heiher/linux/commits/rnull

[heiher]

https://lore.kernel.org/loongarch/20240304141426.163517-1-wangrui@loongson.cn/