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

分析system_call中断处理过程

使用gdb跟踪分析一个系统调用内核函数（您上周选择那一个系统调用），系统调用列表参见http://codelab.shiyanlou.com/xref/linux-3.18.6/arch/x86/syscalls/syscall_32.tbl ,推荐在实验楼Linux虚拟机环境下完成实验。

实验过程

上一例实验中跟踪调用的是getpid内核函数，本例实验继续使用该系统调用来完成实验。

打开实验环境，获取最新版本的menu

先运行未修改的menu,查看都有哪些功能

接下来，为menu添加getpid系统调用功能

打开test.c文件，添加GetPid()和GetPidAsm()两个系统调用函数

在main()函数中，添加调用函数的语句MenuConfig()

使用make rootfs重新编译menu，并运行

如图所示，实现了实验要求的功能，属于getpid和getpid-asm能够得到值。

跟踪

在 sys_getpid 上打上断点。

分析从system_call开始到iret结束之间的整个过程

（注：该流程图来自互联网，这里借用该图来辅助说明中断流程）

这一过程中，库函数触发了中断，并给出了系统调用号。然后系统通过中断描述符找到对应的中断处理函数。

附：关键函数 ENTRY(system_call) /linux-3.18.6/include/linux/linkage.h

    系统调用表 /linux-3.18.6/arch/frv/kernel/entry.S

实验总结

系统通过 int 0x80从用户态进入内核态，在这个过程中系统先保存了中断环境，然后执行系统调用函数。

system_call() 函数通过系统调用号查找系统调用表 sys_cal_table 来查找到具体的系统调用服务进程。

在执行完系统调用后在执行 iret 之前，内核做了一系列检查，用于检查是否有新的中断产生。如果没有新的中断，则通过已保存的系统中断环境返回用户态。

这样就完成了一个系统调用过程

百家号 互联网微风说

微信公众号 weisico-com

转载请注明:微思考学习网-关注技术，分享知识 >> Linux之system_call中断处理过程的分析