[rCore学习笔记 013]GDB跟踪程序
题目要求
请学习 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
- 运行一些初始化并且跳转到
rustsbi- 读取当前的 Hart ID CSR
mhartid写入寄存器a0 - (我们还没有用到:将 FDT (Flatten device tree) 在物理内存中的地址写入
a1) - 跳转到
start_addr,在我们实验中是 RustSBI 的地址
- 读取当前的 Hart ID CSR
- 运行
RustSBI进行硬件的初始化 - 运行
entry.asm分配启动栈,然后把控制权交给rust - 运行内核
所以其实我们现在感兴趣的就是进行了什么样的初始化?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,我们需要将负责第二阶段的 bootloaderrustsbi-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
首先我们就可以欣喜地观察到:
0x0000000000001000 in ?? ()这一行,对应了[[013 GDB跟踪程序#^776ff0|"Qemu 实际执行的第一条指令位于物理地址0x1000"]]0x101a: 0x8000貌似是[[08 内核第一条指令#^b2fc42|原来笔记中]]提到的,跳转到0x80000000的关键,但是同时也观察到这里存储的是0x8000而不是0x80000000.结合后边0x101c: unimp和0x101e: unimp两段相邻内存中的unimp(当数据为 0 的时候则会被反汇编为unimp指令),可以找到跳转的线索- 实际上到跳转貌似代码不多,可以一步步对应地观察,记得之前提到的跳转到
RustSBI之前的[[013 GDB跟踪程序#^ed00ab|一些操作]],我们要尝试看看能不能对应上.
查询[[00 总览#^531b44|RISCV手册]],或者直接使用GPT进行解析,其实这一段指令和[[011 第1章作业题#^038649|作业题中问答题第四题]]的注释部分是对应的:
auipc t0,0x0auipc是一个原子更新即时数(Atomic Update Immediate Plus Constant)指令,它将PC(程序计数器)的高20位与一个20位的立即数相加,并将结果存储到目的寄存器中。在这里,目的寄存器是t0,立即数是0x0,这意味着auipc将把PC的高20位复制到t0中,实质上是将当前指令的地址(去除低12位)存储到t0中。
addi a2,t0,40addi是一个带立即数的加法指令,它将t0寄存器的值与一个12位的立即数相加,并将结果存储到a2寄存器中。在这里,立即数是40(十进制),因此此指令将t0中的值(即PC的高20位)与40相加,结果存储在a2中。
csrr a0,mhartidcsrr是一个从CSR(Control and Status Register)读取指令,它将指定的CSR寄存器的值读取到目的寄存器中。在这里,它从mhartidCSR读取值,并将结果存储在a0寄存器中。mhartidCSR存储了当前Hart(硬件线程)的ID。
ld a1,32(t0)ld是一个长整型(64位)的加载指令,它从内存中加载一个64位的值到目的寄存器中。在这里,它从t0寄存器指向的地址加上32的内存位置加载数据,并将结果存储在a1寄存器中。
ld t0,24(t0)- 类似于上一条
ld指令,这条指令也是从内存中加载一个64位的值,但是这次是加载到t0寄存器中,从t0指向的地址加上24的内存位置加载数据。
- 类似于上一条
jr t0jr是跳转寄存器指令,它将程序计数器(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.

浙公网安备 33010602011771号