分析system_call中断处理过程(Linux)

 ----------------分析system_call中断处理过程-----------------

       这次的实验是要跟踪一下系统调用的中断过程。本人上周的实验其实已经完成过了这个跟踪的过程，没想到这次下半部分就是让跟踪，那我们这次就再来跟踪一下。为了更加明显，这次选择为menu加上上次使用的系统调用的功能，然后对menu的这一系统调用的过程进行跟踪。但是，这次因为在menu中，而system_call都是用汇编实现的，所以最后其实是gdb并没有在断点处停下。这之中究竟发生了什么，我们一会儿通过对汇编码的分析来具体说明。

      （其实，gdb对汇编码是可以调试的。对系统调用的汇编调试可以参考本人的上次实验的跟踪过程。具体跟踪内容不同，方法仅供参考哟！)

开始实验

       本次实验还是使用上次的系统调用getpid（系统调用号为0x14）。

       先为menu加上该功能。

       重新编译运行。

       验证新增加的功能。分别输入getpid与getpid-asm命令，发现输出正确。

       重新启动menu，加上-s与-S参数，准备调试。

       利用gdb调试，在system_call与sys_getpid均设置断点，然后继续运行。

       等待menu启动后，输入命令getpid-asm。

       发现gdb停在了sys_getpid断点处。继续运行。

       发现结果直接执行结束了！！！

       这也就是说，我们设置了两个断点system_call与sys_getpid，但是gdb只在sys_getpid处停下了，在system_call处却没有停下。而system_call对我们理解系统调用的执行过程才是最重要的部分。

       我们再试一次，当gdb在sys_getpid处停住后，一直使用ni命令，逐汇编码进行调试，执行一段指令后，发现gdb跟踪不到了。

       看来我们只好对system_call的源代码进行分析了。

       打开system_call的源代码。

       可以看到，原来system_call的源代码是用汇编完成的，system_call仅是一个入口，只不过之前声明了一下，所以gdb可以在此处设置断点，但是在运行到此处时，gdb便不好把它当作一个正常的函数来调试，因此出现了上面的情况。（其实只要对纯汇编代码设置断点，给gdb一个区分的标识，还是可以调试的。）

       因为我们的重点是研究system_call的执行情况，所以我们就不跟踪调试了，直接对其源代码进行分析吧。

总结：

       分析过system_call的源代码，整个处理流程也就基本清晰了，结合之前的知识，对整个系统调用发生中断的过程，大致可以用表示成下图。

       进入内核态后相信的执行过程，大致可以用表示成下图。

-----------------------------END--------------------------------

                     刘建鑫 + 原创作品转载请注明出处 + 《Linux内核分析》MOOC课程

                     http://mooc.study.163.com/course/USTC-1000029000

------------------------------------------------------------------