分析system_call中断处理过程

Posted 2020-09-06 somnus赤系

李亚健    《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现场，然后返冋被中断进程或新进程，继续往下执行