实验五:分析 system_call 中断处理过程
一、重新编译系统内核,增加自己定义的系统调用函数
首先找到上次编写的两个系统调用函数,一个是直接调用,另一个是通过内嵌汇编语言调用getpid这个系统调用函数,两个代码设置如下:
int getpid_2806(){
int pid=getpid(),ppid=getppid();
printf("pid=%d ppid=%d\n",pid,ppid);
}
int getpid_asm_2806(){
int ans=-1;
asm volatile(
"mov $0x14,%%eax\n\t"
"int $0x80"
:"=r"(ans)
);
printf("pid=%d\n",ans);
}
将这两个函数放入LinuxKernel/menu中的test.c文件中,并在test.c中的main函数加入两个MenuConfig函数进行配置:
MenuConfig("getpid","test system_call_1",getpid_2806);
MenuConfig("getpid_asm","test system_call_2",getpid_asm_2806);
在shell中输入命令make rootfs对menu内核进行重新编译,再次加入menu界面时输入help就可以看到上面两个新增加的函数,经过测试可以成功调用:
二、使用 gdb 跟踪分析一个系统调用内核函数
在小实验一的基础上,我们直接调用首先通过一个shell窗口实现qemu的冻结,另一个shell对getpid的对应系统调用底层函数sys_getpid设置断点:
可以看到这个对应的系统底层调用函数sys_getpid是位于kernel/sys.c中的817行,当输入c继续运行内核时可以看到内核其实正常运行,help中同样存在上述两个自定义的系统调用函数,然后当使用系统调用函数getpid_asm时可以发现无法继续追踪,qemu中的函数调用也无法正常进行,这意味着底层系统调用函数对应的断点设置是有效的:
三、分析从 system_call 开始到 iret 结束之间的整个过程
如下图所示,system_call在start_kernel里初始化,在执行int 0x80后,cpu会从system_call开始执行。系统调用执行是,首先是save_all保留现场,找到system_call和sys_call_table,再通过restore_all对保留的现场进行复原,返回到系统中的用户态结束。