系统调用的三层机制（下）
给MenuOS增加命令
首先进入LinuxKernel文件夹，删除menu目录，然后git clone克隆一个新版本的menu，新版本的menu中已经添加了time和time-asm系统调用。进入menu之后运行make rootfs脚本自动编译生成根目录系统。
在进行make rootfs时发现出错，如下图所示。后发现是因为在LinuxKernel文件夹下执行的该命令，应该进入到menu目录下执行。但有一个疑问是通过ls命令查看发现rootfs文件在LinuxKernel文件夹中，menu下并没有，所以不太清楚为什么要在menu目录下执行make rootfs命令(Ｔ▽Ｔ)
make rootfs成功，输入help命令可以看到新增的两个系统调用。
增加上周实现的getpid
在test.c中加入getpid()，然后使用MenuConfig命令即可添加新命令。
make rootfs成功后，输入help命令可以看到新增的getpid，然后输入getpid命令成功返回pid的值。
使用gdb跟踪系统调用内核函数sys_time
对time命令所用到的系统调用内核处理函数进行调试跟踪，首先用如下命令启动内核，可以看到它被冻结起来。
cd.. /*返回到LinuxKernel目录下*/
qemu -kernel linux-3.18.6/arch/x86/boot/bzImge -initrd rootfs.img -S -s
再打开一个窗口，水平分割启动gdb，然后用如下命令把内核加载进来，建立连接。
file linux-3.18.6/vmlinux
target remote:1234这里在连接1234端口的时候报错“连接超时”，经尝试发现是因为前面将冻结的qemu窗口关掉了。不关掉窗口执行下面的命令则连接成功。
在start_kernel处设置断点，按“c”继续执行，系统开始启动并停在断点处。
time系统调用是13 号系统调用对应的内核处理函数即sys_time，所以在sys_time设置断点，启动MenuOS后执行time命令，程序停在sys_time处。
通过list命令列出sys_time对应的代码。
gdb中单步调试命令有：step和next。step逐语句，跳入自定义函数内部执行；next逐过程，函数直接执行。这里使用s进行单步执行如下图所示：
再设置断点在system_call处，执行发现还是停在了sys_time处，因为system_call是一段特殊的汇编代码，而且内部没有严格遵守函数调用堆栈机制，gdb无法对其进行跟踪。
system_call汇编代码分析
int 0x80和system_call时通过中断向量进行匹配的，系统调用用户态接口和系统调用的内核处理函数是通过系统调用号进行匹配的。system_call就是系统调用的处理过程，如下为system_call简化后的代码。
ENTRY(system_call)
RINGO_INT_FRAME
ASM_CLAC
push1_cfi %eax /*保存系统调用号*/
SAVE_ALL /*保存现场，将用到的所有CPU寄存器保存到栈中*/
GET_THREAD_INFO(%ebp) /*ebp用于存放当前进程thread_info结构的地址*/
test1 $_TIF_WORK_SYSCALL_ENTRY,TI_flags(%ebp)
jnz syscall_trace_entry
cmp1 $(nr_syscalls),%eax /*检查系统调用号（系统调用号应小于NR_syscalls）*/
jae syscall_badsys /*不合法，跳入异常处理*/
syscall_call:
call *sys_call_table(,%eax,4) /*合法，对照系统调用号在系统调用表中寻找相应的系统调用的内核处理函数*/
movl %eax,PT_EAX(%esp) /*保存返回值到栈中*/
syscall_exit:
testl $_TIF_ALLWORK_MASK, %ecx /*检查是否需要处理信号*/
jne syscall_exit_work /*需要，进入 syscall_exit_work*/
restore_all:
TRACE_IRQS_IRET /*不需要，执行restore_all恢复，返回用户态*/
irq_return:
INTERRUPT_RETURN /*相当于iret*/整体上理解系统调用的内核处理过程
从系统调用处理的入口开始，可以看到SAVE_ALL保存现场，然后找到syscall_call和sys_call_table。 call *sys_call_table(,%eax,4) 就是调用了系统调用的内核处理函数，之后restore_all和INTERRUPT_RETURN用于恢复现场并返回到用户态。在这一过程中可能会执行syscall_exit_work进行进程调度和信号处理。流程图如下：
