2019-2020-6 20199317《Linux内核原理与分析》第六周作业
第5章 系统调用的三层机制(下)
1 给MenuOS增加命令
首先进入LinuxKernel目录下,用rm -rf menu强制删除当前的menu目录,然后用git clone重新克隆一个新版本的menu,如下图所示:
新版本的menu中已经将上一章做的两个系统调用添加进去了,在test.c里我们看到添加的两个系统调用,如下图所示:
可以看到在test.c里的main()函数增加了增加了两行代码,一个是MenuConfig("time"),另一个是MenuConfig("time-asm"),从这里看出如果要给MenuOS增加新的命令,只需要使用MenuConfig命令,并增加对应的函数即可。
接下来进入menu目录下,运行make rootfs脚本就可以自动编译并自动生成根文件系统,这时打开了menu镜像,如下图所示:
在MenuOS菜单中输入help命令可以看到新增了 两条命令,输入time命令和time-asm命令可以看到运行结果,如下图所示:
2 使用gdb跟踪系统调用内核函数sys_time
用“qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S”命令先把内核启动一下,可以看到被冻结起来了,代码没有被运行,如下图所示:
再另外打开一个shell窗口,用Ctrl+Shift+O实现水平分割
启动gdb,把内核加载进来,建立连接。这里用到的代码为:
1 file linux-3.18.6/vmlinux
2 target remote:1234
在这个地方可以看到出现了一个问题:在输入target remote:1234命令时,显示连接超时,这是因为我关掉了另一个Shell打开的MenuOS菜单,重新输入qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S命令打开之后,显示的是连接成功。
接下来就可以设置断点了,在这里用break start_kernel设置一个断点,在此之前内核一直是stop状态,如果按“c”则继续执行,系统开始启动,并启动到start_kernel函数的位置停在断点处,如下图所示:
time系统调用是13号系统调用对应的内核处理函数,即sys_time。接下来在这里用break sys_time设置一个断点,按“c”继续执行,启动MenuOS后执行time命令,程序会停到sys_time这个函数的位置,time命令执行到一半将卡在那里,如下图所示:
通过list命令列出sys_time对应的代码如下图所示:
使用s命令单步执行进入get_seconds(),然后用gdb的finish命令把这个函数全部执行完,再单步执行,一直到return i,获得的就是当前系统时间time的数值。
当执行int 0x80时,CPU会自动跳转到system_call函数,所以我们把断点设置到system_call,并继续执行,如下图所示:
可以看到在MenuOS中执行time-asm命令时,还是停在了原先设定的sys_time这个位置,在system_call这个位置并不能停下。sys_call是一段特殊的汇编代码,只能调试系统调用的内核函数和其他内核函数的处理过程,且system_call还有一个函数原型声明,但它并不是一个普通的函数,,只是一段汇编代码的起点,且内部没有严格遵守函数调用堆栈机制,所以gdb不能完成跟踪执行过程的任务。
3 系统调用在内核代码中的处理过程
3.1 中断向量0x80和system_call中断服务程序入口的关系
在用户态中有一个系统调用xyz(),xyz()系统调用库函数里面用了SYSCALL(在这里即为int 0x80)来触发系统调用,其中中断向量0x80对应system_call中断服务程序入口。
在start_kernel函数里调用的trap_init函数中有一段代码如下:
838#ifdef CONFIG_x86_32
839 set_system_trap_gate(SYSCALL_VECTOR, &system_call);
840 set_bit(SYSCALL_VECTOR, used_vectors);
841#endif
这里通过set_system_trap_gate函数绑定了中断向量0x80(这里的SYSCALL_VECTOR是系统调用的中断向量0x80)和system_call中断服务程序入口后,一旦执行int 0x80,CPU就直接跳转到system_call这个位置来执行,即系统调用的工作机制在start_kernel里初始化好之后,CPU一旦执行到Int 0x80指令就会立即跳转到system_call的位置。
3.2 在system_call汇编代码中的系统调用内核处理函数
system_call这一段代码就是系统调用的处理过程,系统调用是一个特殊一点的中断(或称之为软中断),这一段代码中也有保存现场SAVE_ALL和恢复现场restore_all的过程。同时,system_call_table是一个系统调用的表,EAX寄存器传递的系统调用号,使用者在调用它时会根据EAX寄存器来调用对应的系统调用内核处理函数。
简化后的system_call代码为:
ENTRY(system_call) RING0_INT_FRAME ASM_CLAC pushl_cfi %eax #保存系统调用号 SAVE_ALL #保存现场,将用到的所有CPU寄存器保存到栈中 GET_THREAD_INFO(%ebp) #ebp用于存放当前进程thread_info结构的地址 testl $_TIF_WORK_SYSCALL_ENTRY, TI_flags(%ebp) jnz syscall_trace_entry cmpl $(nr_syscalls), %eax #检查系统调用号(系统调用号应小于NR_syscalls) jae syscall_badsys #不合法,跳入异常处理 syscall_call: call *sys_call_table(,%eax,4) #通过系统调用号在系统调用表中找到相应的系统调用内核处理函数,比如sys_time movl %eax, PT_EAX(%esp) #保存返回值到栈中 syscall_exit: testl $_TIF_ALLWORK_MASK, %ecx #检查是否有任务需要处理 jne syscall_exit_work #需要,进入syscall_exit_work,这里是最常见的进程调度时机 restore_all: TRACE_IRQS_TRET #恢复现场 irq_return: INTERRUPT_RETURN #iret
从entry(system_call)开始看这段代码,根据系统调用号来查sys_call_table表中的位置,调用系统调用对应的处理函数,在syscall_exit里面判断当前的任务是否需要处理syscall_exit_work,进入syscall_exit_work,这是最常见的进度调度时机点。
sys_call_table(,%eax,4)中每个表项占4个字节,所以先把系统调用号(EAX寄存器)乘以4,再加上sys_call_table分派表的起始地址,即得到系统调用号对应的系统调用内核处理函数的指针。sys_call_table分派表是由一段脚本根据linux-3.18.6/arch/x86/syscalls/syscall_32.tbl来自动生成的。
3.3 整体上理解系统调用的内核处理过程
system_call流程如下图所示:
总结一下:从系统调用处理过程的入口开始,可以看到SAVE_ALL保存现场,然后找到syscall_call和sys_call_table。call *sys_call_table(,%eax,4)就是调用了系统调用的内核处理函数,之后restore_all和最后有一个INTERRUPT_RETURN(iret)用于恢复现场并返回系统调用到用户态结束。在这个过程当中可能会执行syscall_exit_work,里面有work_pending,其中的work_notifysig是处理信号的。work_pending里还有可能调用schedule,这是一个非常关键的部分。
4 总结
在第四章的基础上,这一章进一步深入内核系统调用处理过程:在用户态下的xyz()就是一个API函数,是系统调用对应的API,其中封装了一个系统调用,这个系统调用 SYSCALL(即为int 0x80汇编语句)来触发中断,对应system_call内核代码的起点,即中断向量0x80对应的中断服务程序入口。从system_call内核代码的起点开始,先是SAVE_ALL保存现场,再是检查EAX寄存器中保存的系统调用号的正确性,接着根据系统调用号在sys_call_table这个分派表查找相对应的系统调用内核处理函数sys_xyz()的入口,得到这个函数的返回值保存到栈中,然后在syscall_exit里面判断当前的任务是否需要处理syscall_exit_work,进入sys_exit_work,进行进程调度,调度完之后就会跳转到restore_all,恢复现场返回系统调用到用户态。
posted on 2019-10-26 15:29 20199317-程峥华 阅读(216) 评论(0) 编辑 收藏 举报