@jiegec @wyfcyx @wangrunji0408 @LyricZhao @xy-plus

之前在重构教程时，本着简洁性的目的，在抄 V2 教程时修改了线程切换的过程，现在看会对内核结构有一定影响。这里说明一下情况，询问大家意见。

• 旧方法（V2）
  • 中断时保存 Trap Frame，然后用一个类似于协程 yield 的方式保存上下文并切换到 idle thread。之后 idle 进行线程调度并上下文切换到另一个线程，这个线程再执行原先 yield 之后的内容，即 restore Trap Frame。
  • 中断时，用户线程各自设有内核栈，内核线程直接使用自己的栈
• 新方法（V3）
  • 中断时保存 Trap Frame，在中断处理中直接进行线程调度，然后加载另一个线程的 Trap Frame。
  • 中断时，所有用户线程公用一个内核栈（因为不会在一个用户线程中断处理完成前启动另一个用户线程），内核线程使用自己的栈

一个显著的区别在于，V2 中会有内核线程来处理调度，而 V3 中则没有（在教程最后状态，不运行任何内核线程）。

如果要在 V3 的系统上继续开发，我认为可能会涉及更多在中断时进行的任务（比如系统调用），而不怎么会用到内核线程。内核线程如果需要进行一些高权限操作，可能需要进行系统调用或者暂时关闭中断。

不过我不清楚在多核上会出现什么情况？zCore（我只粗略看了一下）好像统一了 Trap Frame 和 Context，但是切换线程还是要分两层来切换，这样做是不是有什么优势我没有注意到（比如之后实现 async）？

关于以前提到过的内核线程 bug

目前的代码存在一个小 bug（但不难解决），即一个内核线程在中断调度的时候，把 Trap Frame 放在了线程自己的栈上，此时如果切换其他线程会先切换页表，然后找不到栈 PageFault。
（如果是用户线程发生中断，中断处理就会用公用的内核栈，它是在所有线程页表中的，所以不会有问题）

它的解决思路其实很简单，就是让内核线程也使用公用的内核栈。（如果大家觉得以 V3 的新思路进行下去没有问题我就这么修）

rust函数中临时申请的数据要么存放在堆中要么存放在栈中，诸如i32,u32,&str等数据存放在栈中，因为他们自身容量较小，且size固定。而另一类可变size的数据，如Vec，String等类型的数据，由于其大小不固定，时刻需要因为长度变化而由操作系统重新分配内存，所以具体信息存放在堆中，只在栈中存储起始指针，长度的“胖指针”。当堆中数据需要被函数调用或者被赋值的时候，由于直接clone堆中信息代价太大，rust倾向于让新变量指向原本存储信息的地址，然而rust本身是一种变量离开作用域便会自动free的语言，两个指向同一个地址的指针会造成内存不安全，因此赋值或者函数调用会造成堆上变量的所有权转移。解决方式有两种，第一种，采用深度复制的方法，使得新获取的变量虽然与原变量内容相同，但是其实是指向其他地址的一个copy。另一种方式，利用&符号来进行借用，表示新变量只是借用了原变量的所有权，并无权释放，而一个变量无论是出借了value所有权还是本身所有权就是从别处借来的，他都无法再向别人出借所有权。不知自己对这块的理解是否有所偏差，欢迎指正！

涉及文件

rCore-Tutorial/os/target/riscv64imac-unknown-none-elf/debug/os

相关段落

GDB 调试方法* 在 GDB 中执行 file target/riscv64imac-unknown-none-elf/debug/os 来加载未被 strip 过的内核文件中的各种符号

遇到问题

gdb中执行加载符号时出现错误： I'm sorry, Dave, I can't do that. Symbol format `elf64-littleriscv' unknown.

操作系统：macOS Catalina 10.15.7 (19H15) 软件版本： riscv64-unknown-elf-gdb: GNU gdb (GDB) 10.1 --host=x86_64-apple-darwin19.6.0 --target=riscv64-unknown-elf qemu-system-riscv64: QEMU emulator version 5.1.0

Big Sur也有此问题，但虚拟机中的Ubuntu 20.04是好的

lab 2中关于堆上内存回收的一个问题

大致描述问题

“在堆上的内存回收出现行为不一致”

在进行lab 2的时候，我对堆上的内存回收机制进行了调试，在如下代码

let mut vec = Vec::new();
for i in 0..100 {
    vec.push(i);
}

输出了符合预期的结果 内存正常地申请回收了

可是当主函数执行到物理页分配部分的代码时

for _ in 0..2 {
        let frame_0 = match memory::frame::FRAME_ALLOCATOR.lock().alloc() {
            Result::Ok(frame_tracker) => frame_tracker,
            Result::Err(err) => panic!("{}", err),
        };
        let frame_1 = match memory::frame::FRAME_ALLOCATOR.lock().alloc() {
            Result::Ok(frame_tracker) => frame_tracker,
            Result::Err(err) => panic!("{}", err),
        };
        println!("{} and {}", frame_0.address(), frame_1.address());
}
panic!("end of rust_main");

输出的结果如下

这里发生的内存分配和回收是由于在使用栈结构实现分配器的时候，用到了Vec，带来了动态的内存分配，但是让我疑惑的是，对于第一种情况下，Vec申请的内存最终都被回收了，而第二种情况下可以看到StackedAllocator中的Vec申请的一块大小为64的内存还没来得及回收，主函数就退出了，为什么这两种情况下Vec内存回收的机制不一样，希望有人能解答我的这个疑问，感谢。

关于lab2实验题的堆的递归定义

题目链接：https://rcore-os.github.io/rCore-Tutorial-deploy/docs/lab-2/practice.html

题面：

这个地方用“循环”这个词似乎不太准确。。用递归定义是否会更好？

以及，这样执行一段时间以后是否会爆栈？

关于Lab2和Lab3中内存分配的一些问题

Lab2和Lab3中实现的内存分配好像每次只能分配一页？

下面是分配器代码：

/// 使用栈结构实现分配器
///
/// 在 `Vec` 末尾进行加入 / 删除。
/// 每个元素 tuple `(start, end)` 表示 [start, end) 区间为可用。
pub struct StackedAllocator {
    list: Vec<(usize, usize)>,
}

impl Allocator for StackedAllocator {
    fn new(capacity: usize) -> Self {
        Self {
            list: vec![(0, capacity)],
        }
    }

    fn alloc(&mut self) -> Option<usize> {
        if let Some((start, end)) = self.list.pop() {
            if end - start > 1 {
                self.list.push((start + 1, end));
            }
            Some(start)
        } else {
            None
        }
    }

    fn dealloc(&mut self, index: usize) {
        self.list.push((index, index + 1));
    }
}

从这个分配器代码看来每次分配只能获得一页内存。
但为什么不实现一次性分配一定大小的内存呢？是因为没必要，还是在rCore-Tutorial里面没实现呢？

上面这个分配器算法实现好像有点问题？

在上面代码中可以看到，每次从 list 中 pop 出一个 (start, end) ，如果 end - start > 1 就从这个对中分配出一个 (start, start + 1)，(start + 1, end)入栈。这是 alloc 的做法。
再来看看 dealloc 的做法：回收内存 (index, index + 1)， 把 (index, index + 1) 进栈。
结合 alloc 的实现我有一个疑问：那这样进栈的 (index, index + 1) 岂不是不能再被分配出去了？因为 index + 1 -index = 1 不符合 end - start > 1 的条件，实现中也没有任何方法让它和剩余的元素合并。这样这个 (index, index + 1) 不是就一直无法被重新分配了吗？

思考：动态分配的内存地址在哪个范围里？

Lab2 动态内存分配

参考答案

在 .bss 段中，因为我们用来存放动态分配的这段是一个静态的没有初始化的数组，算是内核代码的一部分。

个人理解

动态分配的内存应该在堆中吧，而且在“调整内存布局”一节中关于.bss段及Heap段的解释为：

.bss 段：存放被初始化为 0 的可读写数据，与 .data 段的不同之处在于我们知道它要被初始化为 0，因此在可执行文件中只需记录这个段的大小以及所在位置即可，而不用记录里面的数据，也不会实际占用二进制文件的空间

Heap：堆，用来支持程序运行过程中内存的动态分配，比如说你要读进来一个字符串，在你写程序的时候你也不知道它的长度究竟为多少，于是你只能在运行过程中，知道了字符串的长度之后，再在堆中给这个字符串分配内存

在Lab2这一节的代码中，有一段

    let v = Box::new(5);

我用gdb调试输出，也可以看到该变量的位置是在堆空间以上的：

(gdb) print v
$1 = (*mut i32) 0x80a1c960 <os::memory::heap::HEAP_SPACE+8388600>

其它变量可以用gdb输出，但无法看到在内存中的位置

而且我在维基百科上查到：

在采用段式内存管理的架构中，BSS段（bss segment）通常是指用来存放程序中未初始化的全局变量的一块内存区域。BSS是英文Block Started by Symbol的简称。BSS段属于静态内存分配。.bss section 的空间结构类似于 stack

结合以上，我认为 .bss 段是存放全局静态变量的

所以为什么参考答案说动态分配的内存在 .bss 段中呢？

参考文献

• Lab0 调整内存布局
• BSS段 - 维基百科

欢迎提出任何问题

涉及文件

docs/lab-1/guide/part-4.md

相关段落

文中的代码片段 os/src/interrupt.asm

遇到问题

太长了。建议采用asm macro等方式，精简代码；如果不能精简代码，可以精简文档中的代码片段 比如:

 SAVE    x3, 3 
 ....
 SAVE    x31, 31

关于实验一的一些思考

在分析 Lab1 的代码过程中，遇到一些问题，其中包括在源码中注释的思考题，和我本人对实验代码提出的一些疑问。希望同学们能指出错误，并且给出建议。

思考题1

思考：sscratch的值最初是在什么地方写入的？
sscratch的作用：
在核（hart）运行用户态代码的时候，sscratch用来保存一个指向内核态上下文的指针。在trap handler的开始部分，sscratch和一个用户寄存器交换值来提供一个initial working register。
因此本人猜测sscratch的值最初是开机启动后操作系统运行第一个用户态程序的时候写入的。（不确定）

思考题2

思考：a0是在哪里被赋值的？（有两种情况）

• 在进入函数handle_interrupt之前的参数准备阶段被赋值；
• 从handle_interrupt返回时作为返回参数被赋值。

思考题3

思考：为什么不恢复scause和stval？如果不恢复，为什么之前要保存？
本人认为scause和stval不需要恢复，之前也没有保存。
从这两个寄存器的作用出发思考，scause指示发生异常的种类，而stval保存了trap的附加信息：出错的地址或者非法指令本身。因此这两个寄存器只在中断出现的时候派上用场，在一般情况下不影响程序的运行，而保存上下文的目的就是要保证中断处理完之后回到原来中断的地方程序能继续运行，从这个角度来看就不必保存这两个寄存器。而又回到之前为什么scause和stval包含在数据结构Context中的问题，既然不需要保存，自然就不需要放在Context里面了。

对实验代码的疑问

在恢复上下文过程中，有这样一条指令：
os/src/interrupt/interrupt.asm

mv      sp, a0

这是从handle_interrupt 中的返回值a0中读取sp，而a0 同时也是作为调用参数传入到handle_interrupt中的。
疑问是：这样的实现方法不是会有风险吗？
因为后面无论是恢复 CRSs 还是恢复通用寄存器，都与sp的值相关，如果返回值不对，或者说在handle_interrupt中修改了a0的值，那么后面的恢复上下文过程就无法正确执行，导致系统崩溃。在x86架构中的函数调用机制使用了一种栈帧结构，本人觉得与实验代码的恢复sp的机制相比，栈帧结构更为完全。
另外，在实验代码有这么一行注释：

// 返回的 Context 必须位于内核栈顶

也就是说这里返回的指针必须指向内核栈的栈顶。
这不正反映了这个机制的不稳定性吗。
欢迎同学们参与讨论。

RISC-V汇编如何在屏幕输出字符串

大致描述问题

如下汇编代码如何正确输出字符串hello world?

代码

.section .text
.global _start
_start:
    lui     a1, %hi(msg)
    addi    a1,a1,%lo(msg)
    #jalr   ra,puts
    call puts
2:  j       2b

.section .rodata
msg:
    .string "hello world\n"

如题，写完以后虽然可以通过编译并运行，但是，如何验证Allocator的正确性呢？

println! 宏因为禁用 std 而不能使用，对这一个 Allocator 进行单独的测试可行吗？Rust 是否支持类似 Java 一样的单个文件的测试（每个 Java 文件都是一个类，可以单独定义 main 函数并调试运行）？

大家都是怎么测试的？只能在整个项目的 main.rs 里面测试吗？

欢迎提出任何问题

环境

• rustc 1.62.0-nightly
• wsl2 Ubuntu 20.04

遇到问题

安装环境时，cargo install cargo-binutils 失败。
安装依赖clap v2.34.0时，提示：

error[E0658]: `if` is not allowed in a `const fn`
  --> /home/ruiqurm/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/clap-2.34.0/src/app/settings.rs:7:1
   |
7  | / bitflags! {
8  | |     struct Flags: u64 {
9  | |         const SC_NEGATE_REQS       = 1;
10 | |         const SC_REQUIRED          = 1 << 1;
...  |
51 | |     }
52 | | }
   | |_^
   |
   = note: see issue #49146 <https://github.com/rust-lang/rust/issues/49146> for more information
   = help: add `#![feature(const_if_match)]` to the crate attributes to enable
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: `if` is not allowed in a `const fn`
  --> /home/ruiqurm/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/clap-2.34.0/src/args/settings.rs:6:1
   |
6  | / bitflags! {
7  | |     struct Flags: u32 {
8  | |         const REQUIRED         = 1;
9  | |         const MULTIPLE         = 1 << 1;
...  |
28 | |     }
29 | | }
   | |_^
   |
   = note: see issue #49146 <https://github.com/rust-lang/rust/issues/49146> for more information
   = help: add `#![feature(const_if_match)]` to the crate attributes to enable
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

   Compiling addr2line v0.17.0
   Compiling regex v1.5.5
error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0658`.
error: could not compile `clap`.

尝试添加标志-Z minimal-versions : cargo install cargo-binutils -Z minimal-versions
在编译backtrace v0.3.5处失败：

Compiling backtrace v0.3.5
error[E0425]: cannot find value `RTLD_LAZY` in crate `libc`
  --> /home/ruiqurm/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/backtrace-0.3.5/src/dylib.rs:30:70
   |
30 |         let ptr = libc::dlopen(name.as_ptr() as *const c_char, libc::RTLD_LAZY);
   |                                                                      ^^^^^^^^^ not found in `libc`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0425`.
error: could not compile `backtrace`.

（可能的）解决方案

切换nightly到stable:

rustup override set stable

问题描述

本小节实验指导书上选择的gdb-client为rust-gdb，但rust-gdb原生不支持riscv指令集。实际上应该选用riscv64-unknown-elf-gdb。

在rCore-Tutorial实验指导书上的位置

链接: 第一章/构建裸机运行时执行环境/设置正确的程序内存布局

更进一步分析

寻求一下rustlings error_handling 部分的error6.rs的解答思路 (Rustings好像这一部分有变化，有的版本可能没有error6) 题目链接：
https://github.com/rust-lang/rustlings/blob/main/exercises/error_handling/errors6.rs

我们的实现中，我们的 target 设置为了 riscv64gc-unknown-none-elf ，这应该是包含了 RISCV 的 M 扩展的 （riscv64gc = RV64IMAFDC ISA）。

然而在 entry.asm 中使用 mul 指令时报错：

删除图中 mul 行后不会报错，且能正常运行第一章的实现。