首页 > 代码库 > 分析system_call中断处理过程

分析system_call中断处理过程

李亚健    《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000

一、实验过程

使用gdb跟踪分析一个系统调用内核函数(上周选择的那一个系统调用)

1.进入实验楼环境,进入LinuxKernel:

rm menu -rf

git clone https://github.com/mengning/menu.git  从github中克隆

cd menu

make rootfs

技术分享

2.给menuOS增加自己的内容:

<1>在test.c中的main函数里增加MenuConfig

<2>增加对应的a.c函数和a_asm.c函数

<3>make rootfs 自动编译脚本

3.开始调试:

qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S

技术分享

gdb  file linux-3.18.6/vmlinux

gdb  target remote:1234

技术分享

查询4号系统调用,设置断点:   b a_asm

gdb  c

可以看到:Break point 2,at time.c:63

gdb  s

一直按n单步执行会进入schedule函数。

a_asm返回后进入会汇编代码处理的gdb不好追踪。

执行int 0x80执行后system_call对应的代码

gdb  b system_call

可以找到entry_32.s,line 477.

 

二、分析system_call对应的汇编代码的工作过程

1.Trap_init():Set_system_trap_gate  Set_bit

2.看老师简化后便于理解的system_call伪代码

3.在entry_32.S 系统调用就是特殊的中断 存在保护和恢复现场

4.SAVE_ALL  Sys_call_table就是调用sys_time

5.先保存返回值 Syscall_exit_work  没有则返回到用户态。

6.INTERRUPT_RETURN <=> iret,结束。

技术分享

字很难看,见谅!

 

三、对“系统调用处理过程”的理解:

1、用户态进程调用int 0x80(或system_call),中断进程,保护现场,让CPU停止当前工作转为执行系统内核中预设的一些任务,然后进入才能进入内核态;调用结束后       又会恢复现场回到内核态。

2、中断后会对调用的任务进行各种检查,并进行调度,完成调用后,再进行检查,才能执行iret返回。 

3、将处理机状态由用户态转为系统态。之后,由硬件和内核程序进行系统调用的一般性处理,即首先保护被中断进程的CPU环境,将处理机状态字PSW、程序计数器PC、系统调用号、用户找指针以及通用寄存器内容等压入堆栈,然后,将用户定义的参数传送到指定的地方保存起來。分析系统调用类型,转入相应的系统调用处理子程序。为使不同的系统调用能方便地转向相应的系统调用处理子程序,在系统中配置了一张系统调用入口表。表中的每个表目都对应一条系统调用,其中包含该系统调用自带参数的数目、系统调用处理子程序的入口地址等。内核可利用系统调用号去查找该表,即可找到相应处理子程序的入口地址而转去执行它。在系统调用处理子程序执行完后,恢复被中断的或设置新进程的CPU现场,然后返冋被中断进程或新进程,继续往下执行

分析system_call中断处理过程