码迷,mamicode.com
首页 > 数据库 > 详细

实验作业:使gdb跟踪分析一个系统调用内核函数

时间:2016-03-23 19:44:55      阅读:208      评论:0      收藏:0      [点我收藏+]

标签:

实验作业:使gdb跟踪分析一个系统调用内核函数(我使用的是getuid)

20135313吴子怡.北京电子科技学院

【第一部分】 根据视频演示的步骤,先做第一部分,步骤如下

①更新menu代码到最新版

技术分享

②在代码中加入C函数、汇编函数

技术分享

③在main函数中加入makeconfig

技术分享

④make rootfs

技术分享

⑤可以看到qemu中增加了我们先前添加的命令:

技术分享

⑥分别执行新增的命令

技术分享

【第二部分】gdb跟踪分析一个系统调用内核函数

①进入gdb调试

技术分享

②设置断点,继续执行:

技术分享

③相对应的得到这样的结果:

技术分享

④查看我所选用的系统调用的函数:

技术分享

⑤设置断点在sys_getuid16处:

技术分享

⑥发现执行命令getuid时并没有停下

技术分享

⑦反而在执行getuid_asm时停下了

技术分享

技术分享

⑧直接结束若干次单步执行,然后继续往下单步执行,发现出现了进程调度函数,返回了进程调度中的一个当前进程任务的值。

技术分享

技术分享

⑨设置断点于system_call处。发现可停,而继续执行时,刚才停下的getuid_asm也返回了值。

技术分享

注意:视频中提及:system_call不是一个正常的函数,分析较有难度,老师作业中并没有要求,也没有布置为作业。因此于此处截止。

【第三部分】system_call到iret过程流程图

技术分享

【第四部分】遇到的问题

在视频中讲解时:当在qemu中输入time时,在设置断点的前提下是会停下的。而我的操作中,输入getuid没有停下,而是在getuid_asm时停下了。这不知道为啥,反复做了好多次还是没解决。甚至重头开始做也还是一样。

已解决的问题:

1.目录很重要!!!!由于很多命令乱用路径,导致做到后面的时候才发现克隆位置出错、编译位置找不到文件等等问题!这种问题不用ls或者不返回去看视频很难发现!因此细心很重要!!!!!target remote连接超时也是很大原因是目录不对!还有gdb开始的位置不对,没有进入到LinuxKernel里面。

【第五部分】博客内容细节

(分析system_call对应的汇编代码的工作过程,系统调用返回iret之前的进程调度时机)

知识点总结请走链接:点我!

【第六部分】总结

“系统调用处理过程及到中断处理过程的推广”

具体的系统调用与系统调用号绑定,然后都记载在一个系统调用表内,每次使用系统调用时都是通过这样的绑定关系,由系统调用号去找系统调用表然后查找到所对应的系统调用的位置。

同理,中断处理过程也是一样的,它也是经由中断向量号作为索引去查表,然后执行相应的具体的中断处理程序去处理中断。

简而言之就是“两个号&两张表”。

【第七部分】附录

作者:吴子怡

学号:20135313

原创作品转载请注明出处

《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000

实验作业:使gdb跟踪分析一个系统调用内核函数

标签:

原文地址:http://www.cnblogs.com/paperfish/p/5312299.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!