分析system_call中断处理过程

一、MesuSO增加getpid和getpid-asm

二、使用GDB跟踪系统调用内核函数sys_getpid

分析system_call中断处理过程 使用gdb跟踪分析一个系统调用内核函数sys_getpid

系统调用列表参见http://codelab.shiyanlou.com/xref/linux-3.18.6/arch/x86/syscalls/syscall_32.tbl

1.gdb file 文件/vmlinux   （把符号表symbol table加载进来）
2.target remote:1234
3.设置断点
4.c执行到断点
5.list查看断点代码

三、系统调用在内核代码中的处理过程

• main.c中start_kernel函数：trap_init()
  
  set_system_trap_gate(SYSCALL_VECTOR,&system_call)
  
  SYSCALL_VECTOR：系统调用的中断向量
  
  &system_call：汇编代码入口
  
  一执行int 0x80，系统直接跳转到system_call。
  

  　　

系统调用返回用户态之前，可能发生进程调度CALL schedule；
进程调度时，可能发生进程上下文切换；

进程间通信时有可能需要notifysig处理信号；
内核抽象成很多中断处理过程的一个集合，提供内核的服务线程当成一般的线程理解。

四、总结部分

执行int0x80指令后，触发中断，跳转到ENTRY(system_call)这是入口，

SAVE_ALL保存现场

调用系统调用处理函数

RESTORE ALL

IRET中断系统处理过程的结束——syscall_exit_work--

---work_pending-----work_notfysing处理信号的，

可能调用schedule,可能会跳转到RESTORE ALL后面恢复现场的工作，然后iret结束掉

内核抽象成很多中断处理过程的一个集合，提供内核的服务线程当成一般的线程理解。

注明“郑伟 + 原创作品转载请注明出处 + 《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000 ”