Analyzing the System_call interrupt processing process
"20135224 Chen Shi + original works reproduced please specify the source +" Linux kernel analysis "MOOC course http://mooc.study.163.com/course/USTC-1000029000"
The first part:
Using GDB to open system call functions and implement trace debugging
Specific steps:
1 Select last week's function and use the original Getpid simple function to implement this experiment
2 use GDB Trace analysis to use code that sets breakpoints at Sys_time and list finds?
3 (note) when entering the System_call gdb can not continue to track, to end the direct quit quit
? Part II:
Analyze Call correspondence function function (Simplified)
(note) The contents of all relevant registers are saved on the stack by Save_all macro. The following are the representations of the simplified functions, which are based on the video:
GET_THREAD_INFO(%ebp):Save current information in EBP
testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags(%esp) jnz syscall_trace_entry:Determine if trace is called
cmpl $(NR_syscalls), %eax jae syscall_badsys:Determine if the system call number exceeds the maximum value
call *sys_call_table(,%eax,4):The number of the system call is actually a sequence number that represents its position in an array of sys_call_table[] in the system.
movl %eax,PT_EAX(%esp):To save the return value of a system call
DISABLE_INTERRUPTS(CLBR_ANY):Masking other system calls
movl TI_flags(%esp), %eax:Register ECX is a universal register, in protected mode, can be used as a memory offset pointer (at this point, DS as a register or segment selector), at this time to return to the system call before preparing
testl $_TIF_ALLWORK_MASK, %eax jne syscall_exit_work :Check whether the signal needs to be processed before exiting the system call
RESTORE_REGS 4? : x86 Schema Recovery Register code
INTERRUPT_RETURNThat is Iret: System call is via soft interrupt instruction
int 0x80 is implemented, and this int 0x80 directive is encapsulated in the function of the C library. (soft interrupts differ from what we often call hard interrupts in that soft interrupts are triggered by instructions, not by hardware peripherals.) )
INT 0x80 The execution of this instruction will cause the system to jump to a preset kernel space address, which points to the system call handler, the System_call function.
Summarize
The System_call function is how to find the specific system call service routine path:
Lookup system Call Table sys_call_table through the system call number, the soft interrupt instruction int 0x80 executes, the system call number is put into the EAX register, the System_call function can read the EAX register get, then multiply it by 4, generate offset address, and then Sys_ Call_table is the base address, add the offset address, you can get the specific system call service routine addresses! Then the system invokes the service routine. It is necessary to note that the system invoke service routine takes only the parameters from the stack, so the parameters are stored in the registers before the System_call executes, and the registers are first pressed into the stack when System_call executes. After the system_call exits, the user can obtain (modified) parameters from the register.
Note: The system call passes through the soft interrupt int 0x80 into the kernel, jumps to the system call handler System_call function, and then executes the corresponding service routine. However, because it represents the user process, the execution process is not part of the interrupt context, but the process context. Therefore, during system call execution, many of the information that can be accessed by the user process can be preempted by other processes and can hibernate. Once the system call is complete, the kernel will be dispatched once the control is handed back to the user process that initiated the call. If you find that a higher priority process or the current process has run out of time slices, you will select a higher priority process or re-select the process execution.
Analyzing the System_call interrupt processing process