Support std on ArceOS

[shilei-massclouds]

Customize a rust-toolchian for ArceOS. The start-point is to support std-library on ArceOS.
Discuss and record the process.

[shilei-massclouds]

Rust-ABI与Function-Call对比实验(1)

名词定义

rust-abi：以extern “Rust” 调用外部函数的方式。虽然调用者和被调用者都是rust程序，但是通常情况下，二者是分别基于不同的target构建的。二者是跨ABI进行调用，不能进行统一的LTO。

function-call：直接调用rust 函数的方式(即最基本的intree调用方式)。下面简称rust-func。

实验目的

对比rust编译器在处理这两种函数调用方式时的异同。针对两个方面：

1. 对比参数和返回值的传递方式的差异
2. rust-abi这种分两次构建再链接的方式影响了统一的LTO，对效率的影响有多大？

本次是实验的阶段1，只针对第1个方面。

实验设置

graph LR
  rust-func-cli --rust-func--> libsys
	rust-abi-cli --rust-abi--> libsys

Loading

1. 通过两种方式分别调用libsys中的函数，打印参数(返回值)本身和参数(返回值)的原始指针；
2. 观察两种方式下，对参数/返回值处理方式的差异；
3. 重点分析rust-abi相对于rust-func，在参数/返回值传递过程中是否增加了额外处理环节。

注：rust-func是基于x86_64-unknown-linux-gnu一次构建完成的；rust-abi是两次构建，先是libsys基于x86_64-unknown-none构建静态库，然后rust-abi-cli基于x86_64-unknown-linux-gnu构建再链接静态库。

实验过程

从github下载实验项目f_a，然后执行，并观察结果

git clone [email protected]:shilei-massclouds/f_a.git
cd f_a/
make run

结果分析

1. 参数传递

   类别	测试项	rust-func	rust-abi
   基本类型	fn sys_call_nn(); fn sys_call_bn(val: usize); fn sys_call_rbn(val: &usize)	传值时复制，传引用即传指针	行为相同
   基本类型构成struct	fn sys_call_sn(layout: Layout); fn sys_call_sn(layout: &Layout)	同上	行为相同
   集合类型	fn sys_call_vn(v: Vec); fn sys_call_rvn(v: &Vec)	vec本身同上；但背后buffer是指针传递	行为相同
   复杂枚举类型*	fn sys_call_enum(n: EnumNumber); fn sys_call_ref_enum(n: &EnumNumber)	同上；Three(String)背后buffer只传指针	行为相同
   字符串类型	fn sys_call_rcn(s: &str); fn sys_call_cn(s: String)	&str就是传指针, String同上面Vec	行为相同

2. 返回值返回

类别	测试项	rust-func	rust-abi
基本类型及struct	fn sys_call_with_struct() -> Layout;	返回值完全复制	行为相同
Option包裹基本类型	fn sys_call_with_opt_struct(input: usize) -> Option;	同上	行为相同
Result包裹基本类型	fn sys_call_usize_with_result(n: usize) -> AxResult;	同上	行为相同
直接返回集合类型	fn sys_call_usize_with_vec() -> Vec; fn sys_call_usize_with_vec() -> Arc<Vec>;	vec本身复制；但背后buffer是指针传递	崩溃segment fault
leak后转成slice再传递	fn sys_call_usize_with_box_leak<'a>() -> &'a mut Vec;fn sys_call_usize_with_vec_leak<'a>() -> &'a mut [usize];fn sys_call_usize_with_vec_leak2<'a>() -> &'a mut [VecItem];	被调用者必须显示调用leak(box.leak或vec.leak)转成slice再传递，调用者用后负责drop	行为相同

1. 涉及的类型定义

   Layout即core::alloc::Layout，由两个i64构成

   EnumNumber的定义

   #[derive(Debug)]
   pub enum EnumNumber {
       One,
       Two(usize),
       Three(String),
   }

   AxResult的定义，其中AxError相当于i32

   #[repr(i32)]
   #[derive(Clone, Copy, Debug, Eq, PartialEq)]
   pub enum AxError {
       Error1,
       Error2,
   }
   
   pub type AxResult<T = ()> = Result<T, AxError>;

   实验结论

   参数传递和返回值返回两个方向上的行为有差别，分别讨论：

   1. 参数传递
      a. 对于基本类型和由基本类型构成的struct，enum，传值时复制，传引用时传指针。
      b. 对于集合类型Vec，String之类，参数本身是复制，而背后的buffer仅仅是传指针（传递前后raw ptr完全相同）。

      小结：在参数传递方面，rust-abi和rust-func的行为相同。

   2. 返回值返回
      a. 如果返回值(或包裹的核心值)是基本类型，以及仅由基本类型构成的struct和enum，rust-abi和rust-func的行为相同，都是完全的内存复制。
      b. 如果返回值(或包裹的核心值)是集合类型，rust-func能够正常处理，是move语义；但是rust-abi采用此方式直接返回时，导致内存崩溃。应该采用如下方式：

       在被调用者callee一方，即返回值的产生方调用**leak**再传递，示例：
       
       ```bash
       #[no_mangle]
       pub fn sys_call_usize_with_vec_leak<'a>() -> &'a mut [usize] {
           let v: Vec<usize> = alloc::vec!(1, 2, 3);
           let v = v.leak();
       
           let ptr = &v as *const _;
           println!("[callee]: ret {:?}; vec.buf {:?}", ptr, (&v).as_ptr());
           v
       }
       ```
       
       在调用者caller一方，即返回值的使用方，用完后显示调用**drop**，示例：
       
       ```bash
       {
               println!("fn sys_call_usize_with_vec_leak() -> &'a mut [usize];");
               let v = unsafe { sys_call_usize_with_vec_leak() };
               let ptr = &v as *const _;
               println!("[caller]: ret {:?}; vec.buf {:?}\n", ptr, v.as_ptr());
               unsafe { core::ptr::drop_in_place(v) }
               println!("[caller]: drop ok!\n");
       }
       ```
      

      小结：当返回值是集合类型时，需要额外操作。但是leak仅仅是获取其背后的指针，没有内存拷贝等操作，所以不会导致明显的效率损失。

   总结：基于实验，仅就参数和返回值处理这方面，目前没有发现rust-abi这种方式会导致编译器为其引入额外的处理代码。对于返回值，我们虽然需要显式执行leak，但是它也不会引起效率问题。另外，extern “Rust”不同于extern “C”，它不像是FFI，更像是消弱版的rust函数调用。

   进一步工作

   工作目标

   研究rust-abi由于消除部分LTO，可能导致的性能问题，即主要是针对上面的第2点。

   基本思路：有三条路可尝试
   1. 研究rust代码，针对rust-func和rust-abi，rustc如何处理参数和返回值；LTO在这方面起到什么作用，有多大的优化空间。(难度：高)
   2. 直接对比rust-func和rust-abi反汇编代码。(难度：中)
   3. 对两种方式执行bench对比测试。但有个问题，如何设计测试，让它更具有代表性。(难度：中)

    第1条路是比较确定的方法，优先考虑。
   

   其它想法：通过上面的工作，找到改进rustc编译器的方法，让rust-abi具有与rust-func具有对等性，包括：
   1. 消除leak之类的附加操作
   2. 生成静态库/动态库时，附加生成meta(类似于rlib的机制)，如此保留足够的类型信息，不再需要extern “Rust”，可以把unsafe变成safe。

[shilei-massclouds]

ArceOS支持Std的路径

有两条路可以走：

扩展rust官方std库，增加ArceOS Target

1. 对rust工具链设计思路的理解

   1. Target决定了构建目标是基于什么平台，x86_64-unknown-linux-gnu指示目标是基于linux的应用，x86_64-unknown-none指示目标基于“空”，即目标本身是裸机程序。前者走std这条路，后者走no_std。我们增加x86_64-unknown-arceos，属于前者那个层次。
   2. Target在工具链源码内部(rust目录)，主要作用是条件编译，且这个条件编译贯穿各个库core\alloc\std以及编译器本身。rust目录下代码会根据这个target指定的配置，去生成不同的代码。

2. 增加ArceOS这个target的主要工作

   Rust官方在设计std标准库时，考虑了各种后端支持的问题，这个设计希望最大程度复用代码，即提供框架和默认实现，而各种后端OS可以选择覆盖默认行为。

   所以我们的工作，一是在框架上增加少量条件编译，二就是在os和sys目录下各增加一个arceos目录，其中代码去覆盖默认行为。

3. 分两次使用不同target构建std应用的原因

   ArceOS本身自然是基于x86_64-unknown-none去构建；而我们在std库中增加的代码只是框架的一部分，这个target：x86_64-unknown-arceos 就需要是与x86_64-unknown-[linux|win|fuchsia|…]同层次的。

   基于不同的target会指导各个库，乃至compiler本身去生成不同的代码。例如core之类的库，基于x86_64-unknown-none这种no_std去编译；和上层基于x86_64-unknown-arceos这种通过std(内部也会依赖core等)，core会生成不同的代码。不只是名字冲突，还有链接时选择哪个的问题。

自定义std库，只是接口与官方std兼容

1. 针对Unikernel或者直接是ArceOS的特点和需要，自己实现一个仅仅是接口上与std等效的库
2. 该std库很可能就表现为升级后的libax

总结

1. 两条路都有意义，前一条让ArceOS称为rust官方支持的target之一，直接支持现有的各种应用；后一条路针对Unikernel深度定制，抛掉官方rust工具链的限制，达到精简和高性能。
2. 从难度上说，前一条在Rust官方工具链的框架下实现，可以复用现有的很多机制和代码，仅是增加了对接ArceOS后端的部分实现，难度较低；后一条路基本是重新实现std库，工作量和风险都比较大。
3. 目前是按照第一条路进行的，我认为在该路径实现之后，对rust工具链有了一定的认识，积累了足够经验，再去实现第二条路比较可行。

[shilei-massclouds]

发现并修复rustc与library不匹配的问题，提交到std_support分支

上周周报提到的关于rust core库编译的问题，如下

这个是我理解错误，这个feature是自举过程中stage0到stage1的基本机制，本身没问题。

问题的实际原因是：编译时使用的rustc的版本和我们实现std库所基于的版本不一致。如下

经对比，我们library基于的实际版本应该是**"nightly-2023-06-17”。**

修改rust-toolchain.toml，并revert当时因为该问题错误提交的一个commit '4884f16’。已经提交到std_support分支。

[shilei-massclouds]

[shilei-massclouds]