2019-2020-1 20199324《Linux内核原理与分析》第六周作业

第五章 系统调用的三层机制(下)

1.给MenuOS增加命令

进入Linuxkernel目录下,强制删除当前menu目录,再重新克隆一个新版本的menu

进入menu,运行make roofts脚本就可以自动编译并且自动生成根文件系统,还可以运行MenuOS系统。

输入help命令可以发现,当前支持的命令比之前多了。增加了两个命令:time,功能是显示系统时间,还有一个是time_asm,功能是使用汇编的方式来显示时间。

下面来增加一个hello的命令,输出“hello 你的学号”。

打开test.c文件:

给MenuOS增加新的命令只需要使用MenuConfig命令即可。在main()函数中增加一行代码。增加对应的函数如下:

使用make roofts自动编译,输入help命令可以发现,比之前多了一个hello命令。

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

启动内核

再打开一个窗口,水平分割,启动gdb,把内核加载进来建立连接

连接到target remote 1234

在 start_kernel 处设置断点,在gdb中按c会在设置断点的 start_kernel 处停下来,使用list可以查看这段代码。

用b sys_time设置一个断点,启动MenuOS后执行time命令,程序会停到 sys_time 这个函数的位置,time命令执行到一半卡在那里。

gdb调试可以看到Breakpoint在 linux-3.18.6/kernel/time/time.c 中的这个文件,因为是使用宏定义,所以无法直接看到 sys_time。
使用list命令列出的sys_time对应的代码如下:

单步执行,会进入get_seconds() 中所在的 linux-3.18.6/kernel/time/timekeeping.c 文件。

使用finish命令把这个函数全部执行完。

再单步执行,一直到 return i,获得的就是当前系统时间time的数值。

再设置一个断点system_call,继续执行,会发现time函数返回了。

但是在 MenuOS 中执行 time-asm 命令时候,还是停在了原先设定的 sys_time 这个位置,在 system_call 这个位置它并不能停下来。

因为 system_call 不是一个普通的函数,它是一段特殊的汇编代码,只能调试系统调用的内核函数和其他内核函数的处理过程,但gdb不能跟踪 entry_32.s 这个汇编代码。

遇到的问题

问题原因:没有克隆新版本的menu。

解决办法:用git clone克隆一个新版本的menu,就会增加新的命令time和time-asm。

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

system_call流程示意图:

从系统调用处理过程的入口开始,就也可以看到SAVE_ALL保存现场,然后找到syscall_call和sys_call_table。之后restore_all和最后的TNTERRUPT_RETURN(iret)用于恢复现场并且返回系统调用到用户态结束。这个过程可能会执行 syscall_exit_work,需要跳转到 work_pending ,里面有work_notifysig 处理信号,还有 work_resched 是需要重新调度的,这里是进程调度的时机点 call schedule ,调度完之后就会跳转到 restore_all ,恢复现场返回系统调用到用户态。

猜你喜欢

转载自www.cnblogs.com/yangdd/p/11743127.html
今日推荐