~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
刘旸 + 原创作品转载请注明出处
《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
在操作系统上运行的某个应用程序,如果想完成一些实际有用的功能,必然会用到操作系统提供的接口,这些接口被称为系统调用(System Call)。
由操作系统提供的功能,通常应用程序本身是无法实现的。例如对文件进行操作,应用程序必需通过系统调用才能做到,因为只有操作系统才具有直接管理外围设备的权限。又如进程或线程间的同步互斥操作,也必需经由操作系统对内核变量进行维护才能完成。
应用程序的进程通常在用户态下运行,当它调用一个系统调用时,进程进入内核态,执行的是kernel内部的代码,从而具有执行特权指令的权限,完成特定的功能。换句话说,系统调用是应用程序主动进入操作系统内核的入口。
下面我们尝试用gdb跟踪分析一下系统调用的过程。
1.进入实验楼环境,打开终端,定位到LinuxKernel文件夹下。
2.使用rm menu -rf删除掉旧的menu文件夹。
3.输入命令git clonehttps://github.com/mengning/menu.git,下载最新版本的MenuOS。
4.进入到menu文件夹下,使用make rootfs命令编译运行MenuOS,效果如下:
此时运行的MenuOS中还没有我们想要跟踪的系统调用,需要先将其加入到MenuOS中。
5.打开Menu文件夹下的test.c文件,在其中加入两个函数GetPid和GetPidAsm,具体代码如下:
int GetPid()
{
pid_t tt;
tt = getpid();
printf("%u\n",tt);
return 0;
}
int GetPidAsm()
{
pid_t tt;
asm volatile (
"mov $0,%%ebx\n\t"
"mov $0x14,%%eax\n\t"
"int $0x80\n\t"
"mov %%eax,%0\n\t"
:"=m"(tt)
);
printf("%u\n",tt);
return 0;
}
6.找到test.c文件的main函数,在其中加上以下两条语句:
7.再次使用make rootfs命令,重新编译运行MenuOS。
8.在MenuOS中输入命令getpid()(getpid-asm同理)测试我们加入的函数功能是否正常。
9.返回到LinuxKernel文件夹下,输入命令qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S :
10.另开一个终端,输入gdb -q开始gdb调试。
11.按照实验四的方法在start_kernel() 处与 sys_getpid()处设置断点,继续运行MenuOS。
12.第二次继续运行后,在MenuOS中输入命令getpid-asm,可以看到gdb已经开始跟踪sys_getpid():
13.按照实验四的方法列出getpid()的代码,逐条跟踪getpid():
发现在跟踪到syscall_exit_work之后,gdb无法正常跟踪,而是出现了下图的情况:
14.再尝试在system_call处设置断点,发现MenuOS没有在system_call处停下,而是又停在了getpid()处:
分析与总结:
当系统调用发生时,通过中断机制,系统调用例程system_call被调用。system_call由汇编语言和C的代码构成,它的执行过程大概分为4个步骤:
1. 从寄存器中取出系统调用号(system call number)和输入参数,然后将这些寄存器的值压入kernel栈中。这一部分的代码用汇编写成。
2. 根据系统调用号(system call number)查找系统调用分派表(system call dispatch table),找到系统调用服务例程(system call service routine)。用汇编写成。
3.调用查到的系统调用服务例程。这一部分用C语言写成,因为第1步中已经将输入参数保存在kernel栈中,所以在C函数的参数表中能够拿到输入参数,使得系统调用服务例程在表面上看与一个普通的C函数没有区别。
4. 将系统调用服务例程的返回值出栈,重新保存在寄存器中。也采用汇编语言。
第1步中将输入参数寄存器的值压入kernel栈的操作由汇编代码__SAVE_ALL宏完成。
第2步中的系统分派表在kernel代码中以变量sys_call_table表示。查找系统调用服务例程的动作就是从sys_call_table里找系统调用号(存在eax寄存器中)指向的那一项,而sys_call_table中的项在sys_call_table.c文件中定义。
第3步,执行C函数实现的系统调用例程。该例程最多接受6个参数(包括系统调用号),返回值是一个整型。返回值为非负,表示执行成功;返回值为负,表示执行出错。
第4步,调用syscall_exit_work退出系统调用,并从内核态回到用户态。
最后,回到用户态的封装函数中,对返回值eax进行检查。如果eax小于0,则将eax的相反数(即绝对值)存到errno全局变量中,同时将eax值置为-1,这时封装函数返回-1;如果eax大于等于0,则封装函数返回eax的值。
通过以上分析我们猜测,实验第12步中出现的gdb无法继续正常跟踪,应该是因为执行完syscall_exit_work之后,程序执行了一些gdb不支持或者无法跟踪的特殊代码;而第13步中出现的无法在system_call处停止的现象,应该是因为system_call只是包含分析中列出的4个步骤的过程的入口,且参数压栈和查找系统调用服务例程都是用汇编写成,因此只有到第三步调用服务例程(本实验中为getpid)时才能停下。
这里附上system_call执行的简易流程图: