remove all warnings

source/chapter1/2remove-std.rst

@@ -209,6 +209,7 @@
 对于上面这个被移除标准库的应用程序，通过了编译器的检查和编译，形成了二进制代码。但这个二进制代码是怎样的，它能否被正常执行呢？为了分析这些程序，首先需要安装 cargo-binutils 工具集：
 
 .. code-block:: console
+
    $ cargo install cargo-binutils
    $ rustup component add llvm-tools-preview
 

source/chapter1/3first-instruction-in-kernel1.rst

@@ -15,6 +15,8 @@
 
 当编写应用程序的时候，大多数情况下我们只需调用库函数即可在操作系统的支持下实现各项功能，而无需关心操作系统如何调度管理各类软硬件资源。操作系统提供了一些监控工具（如 Windows 上的任务管理器或 Linux 上的 ``ps`` 工具），这些工具可以帮助我们统计 CPU、内存、硬盘、网络等资源的占用情况，从而让我们大致上了解这些资源的使用情况，并帮助我们更好地开发或部署应用程序。然而，在实际编写操作系统的时候，我们就必须直面这些硬件资源，将它们管理起来并为应用程序提供高效易用的抽象。为此，我们必须增进对于这些硬件的了解。
 
+.. _term-physical-address:
+
 计算机主要由处理器（Processor，也即中央处理器，CPU，Central Processing Unit），物理内存和 I/O 外设三部分组成。在前八章我们主要用到 CPU 和物理内存。处理器的主要功能是从物理内存中读取指令、译码并执行，在此过程中还要与物理内存和 I/O 外设打交道。物理内存则是计算机体系结构中一个重要的组成部分。在存储方面，CPU 唯一能够直接访问的只有物理内存中的数据，它可以通过访存指令来达到这一目的。从 CPU 的视角看来，可以将物理内存看成一个大字节数组，而物理地址则对应于一个能够用来访问数组中某个元素的下标。与我们日常编程习惯不同的是，该下标通常不以 0 开头，而通常以一个常数，如 ``0x80000000`` 开头。简言之，CPU 可以通过物理地址来寻址，并 **逐字节** 地访问物理内存中保存的数据。
 
 值得一提的是，当 CPU 以多个字节（比如 2/4/8 或更多）为单位访问物理内存（事实上并不局限于物理内存，也包括I/O外设的数据空间）中的数据时，就有可能会引入端序（也称字节顺序）和内存地址对齐的问题。由于这并不是重点，我们在这里不展开说明，如读者有兴趣可以参考下面的补充说明。
@@ -54,6 +56,8 @@
 
 其中：
 
+.. _term-bootloader:
+
 - ``-machine virt`` 表示将模拟的 64 位 RISC-V 计算机设置为名为 ``virt`` 的虚拟计算机。我们知道，即使同属同一种指令集架构，也会有很多种不同的计算机配置，比如 CPU 的生产厂商和型号不同，支持的 I/O 外设种类也不同。关于 ``virt`` 平台的更多信息可以参考 [#virt_platform]_ 。Qemu 还支持模拟其他 RISC-V 计算机，其中包括由 SiFive 公司生产的著名的 HiFive Unleashed 开发板。
 - ``-nographic`` 表示模拟器不需要提供图形界面，而只需要对外输出字符流。
 - 通过 ``-bios`` 可以设置 Qemu 模拟器开机时用来初始化的引导加载程序（bootloader），这里我们使用预编译好的 ``rustsbi-qemu.bin`` ，它需要被放在与 ``os`` 同级的 ``bootloader`` 目录下，该目录可以从每一章的代码分支中获得。
@@ -62,6 +66,8 @@
 Qemu 启动流程
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
+.. _term-physical-memory:
+
 ``virt`` 平台上，物理内存的起始物理地址为 ``0x80000000`` ，物理内存的默认大小为 128MiB ，它可以通过 ``-m`` 选项进行配置。在本书中，我们只会用到最低的 8MiB 物理内存，对应的物理地址区间为 ``[0x80000000,0x80800000)`` 。如果使用上面给出的命令启动 Qemu ，那么在 Qemu 开始执行任何指令之前，首先两个文件将被加载到 Qemu 的物理内存中：即作为 bootloader 的 ``rustsbi-qemu.bin`` 被加载到物理内存以物理地址 ``0x80000000`` 开头的区域上，同时内核镜像 ``os.bin`` 被加载到以物理地址 ``0x80200000`` 开头的区域上。
 
 为什么加载到这两个位置呢？这与 Qemu 模拟计算机加电启动后的运行流程有关。一般来说，计算机加电之后的启动流程可以分成若干个阶段，每个阶段均由一层软件负责，每一层软件的功能是进行它应当承担的初始化工作，并在此之后跳转到下一层软件的入口地址，也就是将计算机的控制权移交给了下一层软件。Qemu 模拟的启动流程则可以分为三个阶段：第一个阶段由固化在 Qemu 内的一小段汇编程序负责；第二个阶段由 bootloader 负责；第三个阶段则由内核镜像负责。

source/chapter1/5support-func-call.rst

@@ -23,6 +23,8 @@
     - 调用者函数和被调用者函数如何合作保证调用子函数前后寄存器内容保持不变？调用者保存和被调用者保存寄存器的保存与恢复各自由谁负责？它们暂时被保存在什么位置？它们于何时被保存和恢复（如函数的开场白/退场白）？
     - 在 RISC-V 架构上，调用者保存和被调用者保存寄存器如何划分（特别地，思考 sp 和 ra 是调用者还是被调用者保存寄存器？为什么？）？如何使用寄存器传递函数调用的参数和返回值？
 
+.. _term-function-call-and-stack:
+
 函数调用与栈
 ----------------------------
 

source/chapter1/8answer.rst

@@ -184,3 +184,6 @@
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 1. 请学习 gdb 调试工具的使用(这对后续调试很重要)，并通过 gdb 简单跟踪从机器加电到跳转到 0x80200000 的简单过程。只需要描述重要的跳转即可，只需要描述在 qemu 上的情况。
+
+
+.. [#qemu_bootrom] https://github.com/qemu/qemu/blob/0ebf76aae58324b8f7bf6af798696687f5f4c2a9/hw/riscv/boot.c#L300