bug fix: now a0 will not be overwritten after sys_sigreturn

Author: wyfcyx

source/chapter7/4signal.rst

@@ -664,6 +664,7 @@
 最后还需要补充 ``sigreturn`` 的实现。在信号处理例程的结尾需要插入这个系统调用来结束信号处理并继续进程原来的执行：
 
 .. code-block:: rust
+    :linenos:
 
     // os/src/syscall/process.rs
 
@@ -674,20 +675,20 @@
             // restore the trap context
             let trap_ctx = inner.get_trap_cx();
             *trap_ctx = inner.trap_ctx_backup.unwrap();
-            0
+            trap_ctx.x[10] as isize
         } else {
             -1
         }
     }
 
-这里只是将进程控制块中保存的记录了处理信号之前的进程上下文的 ``trap_ctx_backup`` 覆盖到当前的 Trap 上下文。这样接下来 Trap 回到用户态就会继续原来进程的执行了。
+这里只是将进程控制块中保存的记录了处理信号之前的进程上下文的 ``trap_ctx_backup`` 覆盖到当前的 Trap 上下文。这样接下来 Trap 回到用户态就会继续原来进程的执行了。注意在第 10 行，我们将 ``trap_ctx`` 中的 ``a0`` 的值作为系统调用返回值而不是使用 0 这种特定值，不然的话，在返回用户态恢复 Trap 上下文的时候，原来进程上下文中的 ``a0`` 寄存器将会被这些特定值覆盖，使得进程无法在信号处理完成后恢复正常执行。
 
 小结
 --------------------------------------------
 
 信号作为一种软件中断机制和硬件中断有很多相似之处：比如它们都可以用某种方式屏蔽，还细分为全局屏蔽和局部屏蔽；它们的处理都有一定延迟，硬件中断每个 CPU 周期仅在固定的阶段被检查，而信号只有在 Trap 陷入内核态之后才被检查并处理。这个延迟还与屏蔽、优先级和软件或硬件层面的调度策略有关。
 
-这里仅仅给出了一个基本的信号机制的使用和实现的过程描述，在实际操作系统中，信号处理的过程要复杂很多，有兴趣的同学可以查找实际操作系统，如 Linux，在信号处理上的具体实现。
+这里仅仅给出了一个基本的信号机制的使用和实现的过程描述，在实际操作系统中，信号处理的过程要复杂很多，有兴趣的同学可以查找实际操作系统（如 Linux ）在信号处理上的具体实现。
 
 至此，我们基本上完成了“迅猛龙”操作系统，它具有 UNIX 的很多核心特征，比如进程管理、虚存管理、文件系统、管道、I/O 重定向、信号等，是一个典型的宏内核操作系统。虽然它还缺少很多优化的算法、机制和策略，但我们已经一步一步地建立了一个相对完整的操作系统框架和核心模块实现。在这个过程中，我们经历了从简单到复杂的 LibOS、批处理、多道程序、分时多任务、虚存支持、进程支持、文件系统支持等各种操作系统的设计过程，相信同学对操作系统的总体设计也有了一个连贯的多层次的理解。而且我们可以在这个操作系统的框架下，进一步扩展和改进它的设计实现，支持更多的功能并提高性能，这将是我们后续会进一步讲解的内容。