Linux内核分析第五周 扒开系统调用的三层皮（下）

郭皓 原创作品转载请注明出处 《Linux内核分析》MOOC课程 http://mooc.study.163.com/course/USTC-1000029000

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

　　1.给MenuOS增加time和time-asm命令

 rm menu -rf //强制删除原menu文件
 git clone http://github.com/mengning/menu.git //从github中克隆
 cd menu //在menu文件夹下才能正确编译
 make rootfs //运行自动编译脚本，生成根文件系统，启动MenuOS

原来的菜单列表

进入test.c加入上周的getpid

运行结果：

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

PS：我在虚拟机里没有弄出来，没有找到vmlinux，于是在实验楼里完成！

准备进行gdb跟踪

设置断点跟踪

c：继续执行，停在断点处
n/s：单步运行，s进入函数，n不进入

从system_call开始到iret结束的流程图：

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

• main.c中start_kernel函数：trap_init()
• trap_gate函数中，涉及到了系统调用的中断向量和system_call的汇编代码入口
  • SYSCALL_VECTOR：系统调用的中断向量
  • &system_call：汇编代码入口
• 执行int 0x80，系统直接跳转到system_call

system_call到iret之间的主要代码：

SAVE_ALL //保存现场
call *sys_call_table(,%eax,) //调用了系统调度处理函数，eax存的是系统调用号，是实际的系统调度程序。
sys_call_table //系统调用分派表
syscall_after_all//保存返回值
sys_exit_work  //详见解释
restore all //恢复现场（因为系统调用也是一种特殊的“中断”）
INTERRUPT RETURN //也就是iret，系统调用到此结束    

对sys_exit_work的解释：

• 若有sys_exit_work，则进入sys_exit_work:会有一个进程调度时机。
  • work_pending -> work_notifysig，用来处理信号
    • 可能call schedule：进程调度代码
    • 可能跳转到restore_all，恢复现场。

• 若无sys_exit_work，就执行restore_all恢复，返回用户态。

总结：

　　本周通过一个实验来分析系统调用“中断”机制，通过int 0x80触发一个系统调用 ，马上执行系统调用处理函数system_call，最后返回到用户态。而我们主要研究了内核在系统调用过程的代码来分析系统调用，通过gdb单步追踪也可以看出系统调用的过程，方便我们理解。