2021-2022-1 20212809《Linux内核原理与分析》第六周作业

给MenuOS增加命令

首先进入LinuxKernel 文件夹，删除menu目录，然后git clone克隆一个新版本的menu，新版本的menu目录中已经添加了time 和time-asm的系统调用，进入menu之后，运行make rootfs脚本自动编译生成根目录系统。

运行make rootfs时要进入menu目录下执行
当make rootfs成功后，输入help命令可以看到新增的两个系统调用。

增加在上周实验中实现的getpid。

在test.c中加入getpid（），然后使用MenuConfig命令即可添加新命令。
make rootfs成功后，输入help命令可以看到新增的getpid，然后输入getpid命令成功返回pid值。

使用gdb跟踪系统调用内核函数sys_time

对time命令所用到的系统调用内核处理函数进行调试跟踪，首先用如下命令启动内核，可以看到它被冻结起来。

cd ..
qemu -kernel linux-3.18.6/arch/x86/boot/bzImge -initrd rootfs.img -S -s 

再打开一个窗口，水平分割启动gdb，然后用如下命令把内核加载进来，建立连接。

file linux-3.18.6/vmlinux
target remote:1234

在连接端口1234时，要注意：不要关掉之前冻结的qemu窗口 ，之前有遇到这个问题，这里再次提及一次
在start_kernel处设置断点，然后 c 继续执行，系统开始启动并在断点处停止。
time系统调用是13号系统调用，对应的内核处理函数是sys_time,所以在sys_time处设置断点，启动MenuOS后执行time命令，程序在sys_time处停止。

通过list命令列出sys_time 的代码。

进行gdb单步调试命令：step和next。step逐语句，跳进自定义函数内部执行；next逐过程，函数直接执行。这里使用step进行单步执行：

再设置断点再system_call处，执行发现还是停在了sys_time处，因为system_call是一段特殊的汇编代码，而且内部没有严格遵循函数调用堆栈机制，故gdb无法对其进行跟踪。

system_call汇编代码分析

int 0x80 和system_call是通过中断向量匹配的，系统调用用户态接口和系统调用的内核处理函数是通过系统调用号进行匹配的。system_call就是系统调用的处理过程，如下为system_call简化后的代码：

ENTRY(system_call)
    RINGO_INT_FRAME
    ASM_CLAC
    push1_cfi %eax   /*保存系统调用号*/
    SAVE_ALL  /*保存现场，将用到的所有CPU寄存器保存到栈中*/
    GET_THREAD_INFO(%ebp)   /*ebp用于存放当前进程thread_info结构的地址*/
    test1 $_TIF_WORK_SYSCALL_ENTRY,TI_flags(%ebp)
    jnz syscall_trace_entry
cmp1 $(nr_syscalls),%eax   /*检查系统调用号（系统调用号应小于NR_syscalls）*/
    jae syscall_badsys   /*不合法，跳入异常处理*/
syscall_call:
     call *sys_call_table(,%eax,4)   /*合法，对照系统调用号在系统调用表中寻找相应的系统调用的内核处理函数*/
     movl %eax,PT_EAX(%esp)    /*保存返回值到栈中*/
 syscall_exit:  
     testl $_TIF_ALLWORK_MASK, %ecx    /*检查是否需要处理信号*/
     jne syscall_exit_work     /*需要，进入 syscall_exit_work*/
 restore_all: 
     TRACE_IRQS_IRET     /*不需要，执行restore_all恢复，返回用户态*/
 irq_return:
     INTERRUPT_RETURN     /*相当于iret*/

系统调用的内核处理过程

system_call流程示意图中涉及syscall_exit_work内部处理的一些关键点，大致过程是syscall_exit_work需要跳转到work_pending，里面有work_notifysig处理信号，还有work_resched是需要重新调度的，这里是进程调度的时机点call schedule，调度完之后就会跳转到restore_all，恢复现场返回系统调用到用户态。
根据课本上的流程图和简化后的system_call处理过程伪代码和对应的流程图之后。从系统调用处理过程的入口开始，可以看到SAVE_ALL保存现场，然后找到syscall_call和sys_call_table。
work_notifysig是处理信号的；
work_pending里还有可能调用schedule（这是进程切换代码）