Linux第五周学习总结

作者：黎静

一、知识点总结

（一）给MenuOS增加time和time-asm命令

1.更新menu代码到最新版

2.test.c中main函数里，增加MenuConfig()

3.增加对应的两个函数，Time和TimeAsm函数

4.make rootfs自动编译脚本

（二）使用gdb调试跟踪系统调用内核函数sys_time

为处理time函数的系统调用systime设置断点之后，在menuOS中执行time。发现系统停在systime处。继续按n单步执行，会进入schedule函数。

sys_time返回之后进入汇编代码处理，gdb无法继续跟踪。

如果在syscall设置断点（entry32.S），然后输入c之后，发现是不会在sys_call处停下来的（因为这里是一处系统调用函数而不是正常函数）。

（三）系统调用在内核代码中的处理过程

1.系统调用在内核代码中的工作机制和初始化

整个系统调用过程中，时间很重要。

以system_call为例，int 0x80指令与systemcall是通过中断向量联系起来的，而API和对应的sys是通过系统调用号联系起来的。

用户态时，系统调用xyz()使用int 0x80，它对应调用system_call。

右边的处理过程（汇编代码）非常重要，通过系统调用号匹配起来。

2.系统调用机制的初始化

trap_init

函数里面有一个

set_system_trap_gate

函数，其中涉及到了系统调用的中断向量

SYSCALL_VECTOR

和汇编代码入口

system_call

，一旦执行int 0x80，CPU直接跳转到

system_call

来执行。

3.简化后便于理解的

system_call

伪代码

systemcall的位置就在ENTRY（systemcall）处，其他中断的处理过程与此类似。

SAVE_ALL：保存现场

call *sys_call_table(,%eax,4)

调用了系统调度处理函数，eax存的是系统调用号，是实际的系统调度程序

sys_call_table

：系统调用分派表

syscall_after_all

：保存返回值

若有

sys_exit_work

，则进入

sys_exit_work

:会有一个进程调度时机。

work_pending -> work_notifysig

，用来处理信号。

可能call schedule：进程调度代码。

可能跳转到restore_all，恢复现场。

若无

sys_exit_work

，就执行

restore_all

恢复，返回用户态。

INTERRUPT_RETURN <=> iret，结束。

4.简单浏览

system_call

到iret之间的主要代码

1.SAVE_ALL：保存现场

2.syscall_call:调用了系统调用处理函数

3.restore_all：恢复现场（因为系统调用处理函数也算是一种特殊的“中断”）

4.syscallexitwork：如3.中所述

5.INTERRUPT RETURN：也就是iret，系统调用到此结束

二、实验：分析system_call中断处理过程

一）使用gdb跟踪分析一个系统调用内核函数（上周选择的系统调用）——getpid

1.先执行rm menu -rf，强制删除原有的menu文件夹，使用git命令更新menu代码至最新版。

2.在test.c中添加C函数、汇编函数

3.make rootfs，输入help，可以看到qemu中增加了我们先前添加的命令。

system_call到iret过程流程图