题目要求

请学习 gdb 调试工具的使用(这对后续调试很重要)，并通过 gdb 简单跟踪从机器加电到跳转到 0x80200000 的简单过程。只需要描述重要的跳转即可，只需要描述在 qemu 上的情况。

启动调试和监听的指令

使用[[010 基于 SBI 服务完成输出和关机#^fb8fca|之前学到的指令]],开启两个bash,在GDB进行监听的那个bash里进行调试.
题目中提到的tips可以帮助我们专注于调试,而不关心具体的指令.

cd ~/App/rCore-Tutorial-v3/os
make debug

这里的运行都没有问题,但是通过自己的能力去读RISCV的汇编未免有些太难了.但是我们仍然可以选择啃下来,让我们看看官方给了什么tips:

• 事实上进入 rustsbi 之后就不需要使用 gdb 调试了。可以直接阅读代码。rustsbi起始代码 。
• 可以使用示例代码 Makefile 中的 make debug 指令。
• 一些可能用到的 gdb 指令：
  • x/10i 0x80000000 : 显示 0x80000000 处的10条汇编指令。
  • x/10i $pc : 显示即将执行的10条汇编指令。
  • x/10xw 0x80000000 : 显示 0x80000000 处的10条数据，格式为16进制32bit。
  • info register: 显示当前所有寄存器信息。
  • info r t0: 显示 t0 寄存器的值。
  • break funcname: 在目标函数第一条指令处设置断点。
  • break *0x80200000: 在 0x80200000 处设置断点。
  • continue: 执行直到碰到断点。
  • si: 单步执行一条汇编指令。

实际上第一条tip是我们刚刚忽略了的,如果可以直接阅读rustsbi那么明白上电之后会做什么就很简单了,我们从问答题中已知qemu上电之后的步骤: ^ed00ab

1. 运行一些初始化并且跳转到rustsbi
   • 读取当前的 Hart ID CSR mhartid 写入寄存器 a0
   • （我们还没有用到：将 FDT (Flatten device tree) 在物理内存中的地址写入 a1）
   • 跳转到 start_addr ，在我们实验中是 RustSBI 的地址
2. 运行RustSBI进行硬件的初始化
3. 运行entry.asm分配启动栈,然后把控制权交给rust
4. 运行内核

所以其实我们现在感兴趣的就是进行了什么样的初始化?RustSBI的起始地址在哪?后边的行为能不能对应上,这样使得我们对开发的内容更加的熟悉更加的融会贯通.

参考官方给的启动流程,和[[08 内核第一条指令#^6e433b|我们自己的笔记]]:
在Qemu模拟的 virt 硬件平台上，物理内存的起始物理地址为 0x80000000 ，物理内存的默认大小为 128MiB ，它可以通过 -m 选项进行配置。如果使用默认配置的 128MiB 物理内存则对应的物理地址区间为 [0x80000000,0x88000000) 。如果使用上面给出的命令启动 Qemu ，那么在 Qemu 开始执行任何指令之前，首先把两个文件加载到 Qemu 的物理内存中：即作把作为 bootloader 的 rustsbi-qemu.bin 加载到物理内存以物理地址 0x80000000 开头的区域上，同时把内核镜像 os.bin 加载到以物理地址 0x80200000 开头的区域上。

为什么加载到这两个位置呢？这与 Qemu 模拟计算机加电启动后的运行流程有关。一般来说，计算机加电之后的启动流程可以分成若干个阶段，每个阶段均由一层软件或 固件 负责，每一层软件或固件的功能是进行它应当承担的初始化工作，并在此之后跳转到下一层软件或固件的入口地址，也就是将计算机的控制权移交给了下一层软件或固件。Qemu 模拟的启动流程则可以分为三个阶段：第一个阶段由固化在 Qemu 内的一小段汇编程序负责；第二个阶段由 bootloader 负责；第三个阶段则由内核镜像负责。

• 第一阶段：将必要的文件载入到 Qemu 物理内存之后，Qemu CPU 的程序计数器（PC, Program Counter）会被初始化为 0x1000 ，因此 Qemu 实际执行的第一条指令位于物理地址 0x1000 ，接下来它将执行寥寥数条指令并跳转到物理地址 0x80000000 对应的指令处并进入第二阶段。从后面的调试过程可以看出，该地址 0x80000000 被固化在 Qemu 中，作为 Qemu 的使用者，我们在不触及 Qemu 源代码的情况下无法进行更改。 ^776ff0
• 第二阶段：由于 Qemu 的第一阶段固定跳转到 0x80000000 ，我们需要将负责第二阶段的 bootloader rustsbi-qemu.bin 放在以物理地址 0x80000000 开头的物理内存中，这样就能保证 0x80000000 处正好保存 bootloader 的第一条指令。在这一阶段，bootloader 负责对计算机进行一些初始化工作，并跳转到下一阶段软件的入口，在 Qemu 上即可实现将计算机控制权移交给我们的内核镜像 os.bin 。这里需要注意的是，对于不同的 bootloader 而言，下一阶段软件的入口不一定相同，而且获取这一信息的方式和时间点也不同：入口地址可能是一个预先约定好的固定的值，也有可能是在 bootloader 运行期间才动态获取到的值。我们选用的 RustSBI 则是将下一阶段的入口地址预先约定为固定的 0x80200000 ，在 RustSBI 的初始化工作完成之后，它会跳转到该地址并将计算机控制权移交给下一阶段的软件——也即我们的内核镜像。
• 第三阶段：为了正确地和上一阶段的 RustSBI 对接，我们需要保证内核的第一条指令位于物理地址 0x80200000 处。为此，我们需要将内核镜像预先加载到 Qemu 物理内存以地址 0x80200000 开头的区域上。一旦 CPU 开始执行内核的第一条指令，证明计算机的控制权已经被移交给我们的内核，也就达到了本节的目标。

我们可以看到作为bootloader的RustSBI的位置在0x80000000.

那么我们不能看代码,需要啃汇编的部分其实就很少了,就是所谓的[[013 GDB跟踪程序#^776ff0|"固化在 Qemu 内的一小段汇编程序"]].其实刚好页对应了[[08 内核第一条指令#^e44d27|原本笔记]]中需要我们探索的部分.

在GDB中键入x/10i $pc,显示10行等待执行的反汇编:

0x0000000000001000 in ?? ()
│(gdb) x/10i $pc
│=> 0x1000:      auipc   t0,0x0
│   0x1004:      addi    a2,t0,40
│   0x1008:      csrr    a0,mhartid
│   0x100c:      ld      a1,32(t0)
│   0x1010:      ld      t0,24(t0)
│   0x1014:      jr      t0
│   0x1018:      unimp
│   0x101a:      0x8000
│   0x101c:      unimp
│   0x101e:      unimp

首先我们就可以欣喜地观察到:

1. 0x0000000000001000 in ?? ()这一行,对应了[[013 GDB跟踪程序#^776ff0|"Qemu 实际执行的第一条指令位于物理地址 0x1000 "]]
2. 0x101a: 0x8000貌似是[[08 内核第一条指令#^b2fc42|原来笔记中]]提到的,跳转到0x80000000的关键,但是同时也观察到这里存储的是0x8000而不是0x80000000.结合后边0x101c: unimp和0x101e: unimp两段相邻内存中的unimp(当数据为 0 的时候则会被反汇编为 unimp 指令),可以找到跳转的线索
3. 实际上到跳转貌似代码不多,可以一步步对应地观察,记得之前提到的跳转到RustSBI之前的[[013 GDB跟踪程序#^ed00ab|一些操作]],我们要尝试看看能不能对应上.

查询[[00 总览#^531b44|RISCV手册]],或者直接使用GPT进行解析,其实这一段指令和[[011 第1章作业题#^038649|作业题中问答题第四题]]的注释部分是对应的:

1. auipc t0,0x0
   • auipc 是一个原子更新即时数（Atomic Update Immediate Plus Constant）指令，它将PC（程序计数器）的高20位与一个20位的立即数相加，并将结果存储到目的寄存器中。在这里，目的寄存器是t0，立即数是0x0，这意味着auipc将把PC的高20位复制到t0中，实质上是将当前指令的地址（去除低12位）存储到t0中。
2. addi a2,t0,40
   • addi 是一个带立即数的加法指令，它将t0寄存器的值与一个12位的立即数相加，并将结果存储到a2寄存器中。在这里，立即数是40（十进制），因此此指令将t0中的值（即PC的高20位）与40相加，结果存储在a2中。
3. csrr a0,mhartid
   • csrr 是一个从CSR（Control and Status Register）读取指令，它将指定的CSR寄存器的值读取到目的寄存器中。在这里，它从mhartid CSR读取值，并将结果存储在a0寄存器中。mhartid CSR存储了当前Hart（硬件线程）的ID。
4. ld a1,32(t0)
   • ld 是一个长整型（64位）的加载指令，它从内存中加载一个64位的值到目的寄存器中。在这里，它从t0寄存器指向的地址加上32的内存位置加载数据，并将结果存储在a1寄存器中。
5. ld t0,24(t0)
   • 类似于上一条ld指令，这条指令也是从内存中加载一个64位的值，但是这次是加载到t0寄存器中，从t0指向的地址加上24的内存位置加载数据。
6. jr t0
   • jr 是跳转寄存器指令，它将程序计数器（PC）设置为t0寄存器的值。这通常用于实现子程序的返回或循环的迭代。

第三条指令就可以对应上[[011 第1章作业题#^67887c|笔记中]]关于mhartid的存储的描述.

其余的指令可以对应上[[08 内核第一条指令#^e44d27|这里]],对于0x1000 和 0x100c 两条指令的重视.首先第一条指令把pc的值和0x0相加储存在t0中,实际上就是储存了pc的值在t0中,此时t0应该为0x1000,因为之前也说了[[013 GDB跟踪程序#^776ff0|"Qemu 实际执行的第一条指令位于物理地址 0x1000 "]].

这里我们可以直接使用指令来验证:

si
info r t0

得到的结果为:

t0             0x1000   4096

第四条指令从t0寄存器指向的地址加上32的内存位置(即0x1020)加载64位数据，并将结果存储在a1寄存器中,那么目前a1的数据我们不知道,但是可以根据[[011 第1章作业题#^67887c|笔记中]]的作用知道这一句是将 FDT (Flatten device tree) 在物理内存中的地址写入 a1,但是可以用GDB调试验证:

si
info r a1

得到的结果为:

a1             0x87000000       2264924160

第五条指令为从内存中加载一个64位的值，但是这次是加载到t0寄存器中，从t0指向的地址加上24的内存位置(即0x1018)加载64位数据,可以看到0x1018后边每一个地址存四位16进制,这里有个点要注意在RISCV中,数据是小端的,也就是从0x1018读取的数据放在最后4位,这样读出来是0000 0000 8000 0000.

│   0x1018:      unimp
│   0x101a:      0x8000
│   0x101c:      unimp
│   0x101e:      unimp

同样可以使用如下指令验证:

x/1xw 0x1018
x/1xw 0x1019
x/1xw 0x101a
x/1xw 0x101b
x/1xw 0x101c

得到的结果为,可以证明是小端储存的:

(gdb) x/1xw 0x1018 
│0x1018: 0x80000000
│(gdb) x/1xw 0x1019  
│0x1019: 0x00800000
│(gdb) x/1xw 0x101a
│0x101a: 0x00008000
│(gdb) x/1xw 0x101b
│0x101b: 0x00000080
│(gdb) x/1xw 0x101c
│0x101c: 0x00000000

那么同样可以使用验证t0的值:

si
info r t0

得到的结果:

t0             0x80000000       2147483648

这时候第六条指令就可以完成跳转到0x80000000的任务,后续的动作我们就可以看RustSBI的源码了.

查看RustSBI源码

官方也给出了RustSBI源码的具体位置,但是在GitHub上看源码有点太累了,我们可以把源码clone到workspace.

git clone https://github.com/rustsbi/rustsbi-qemu.git

我们可以在/rustsbi-qemu/rustsbi-qemu/src,找到main.rs,找到官方推荐我们阅读的L146.

这里因为中间的实现思路我们是不知道的,只看rust_main函数里的注释和一些函数名称,我们大概可以看出实际上RustSBI是初始化了一个Console,在USART的基础上实现了dbcn和clint的功能,最终实现了一个Console.

TODO 可能需要更了解RISCV和SBI的要求才能完成这一部分的理解.