See system calls from the kernel

This week, I studied Monensin's "Linux kernel Analysis," and, according to the course requirements, experimented with the following:

First, using GDB to track a system call, we chose the code written by the experiment last week, modify the two code into two system calls, put it into the root filesystem, as the system call that this experiment will observe.

Modify the code as follows:

1) C Implementation of system calls

intMkdir_c (intargcChar**argv) {    if(ARGC! =2) printf ("ILlegal parameter!! \ n"); if(MkDir (argv[1]) == -1) {printf ("MKdir error!! \ n"); return-1; }
printf ("Mkdir success!!    \ n "); return 0;}

2) system calls implemented using assembly language

intMkdir_asm (intargcChar**argv) {    if(ARGC! =2) printf ("Illagel parameters!! \ n"); intRET =0; ASMvolatile(            "mov $,%%eax\n\t"            "mov $0x27,%%eax\n\t"            "int $0x80\n\t"            "mov%%eax,%0\n\t"            :"=m"(ret):"b"(argv[1])            ); if(ret = =-1) {printf ("Mkdir error!! \ n"); return-1; }
printf ("Mkdir success!!    \ n "); return 0;}

Open the Lab building environment and enter the menu directory

Cd/home/shiyanlou/linuxkernel/menu

Open the TEST.c file, if the above two pieces of code:

Add two lines of code to the main function to register the two system calls:

Recompile and make the root file system image. Use the QEMU emulation environment to load the kernel and root file system and start the system. For convenience, we use this sequence of commands to write to the makefile file, so simply execute the following command at the terminal:

Make Rootfs

You can complete all the actions:

We can execute the commands we have added.

Next we use the GDB tool to debug the system calls.

First use QEMU to enter debug mode and freeze the kernel:

Start GDB, load the debug symbol table, and start debugging:

Breakpoints are set at the System_call function, but cannot be stopped here, because the Entry_32.s file where the System_call function is the assembler code, GDB has limited debugging capabilities for assembly code.

To understand the process of system call mechanism, we read and analyze the System_call code:

For specific code see: Http://codelab.shiyanlou.com/xref/linux-3.18.6/arch/x86/kernel/entry_32.S

First the kernel to initialize the system call mechanism, we know that Start_kernel is the kernel's entry address, in this function, the system completes a series of initialization work, so the system call mechanism initialization work must be in this function, wherein the TRAP_ The INIT function is responsible for initializing the system invocation mechanism,

In Init/main.c   Start_kernel
553  /* 554     * These use large BOOTMEM allocations and must precede555     * Kmem_cache_init () 556     */557    setup_log_buf (0); 558     pidhash_init (); 559     vfs_caches_init_early (); 560     sort_main_extable (); 561     trap_init (); 562    Mm_init ();

We enter the Trap_init function:

837 838 #ifdef config_x86_32 839    Set_system_trap_gate (Syscall_vector, &system_call); 840     set_bit (Syscall_vector, used_vectors); 841 #endif 842

This piece of code breaks the interrupt vector table 0x80 to the System_call code snippet, and we enter Syscall_vector to see that the macro represents the 0x80:

 - #ifdef config_x86_32 Wuyi# define Syscall_vector            0x80#endif

Next we also analyze the System_call code:

489# system call handler stub490 ENTRY (System_call)491Ring0_int_frame # can't unwind into user space anyway492Asm_clac493Pushl_cfi%eax # Save Orig_eax494Save_all //Saves the current process context because the system call itself is an interrupt, so as with the interrupt mechanism, some information about the current process needs to be saved so that the site can be resumed after the system call is completed 495Get_thread_info (%EBP)496# system Call TracinginchOperation/emulation497Testl $_tif_work_syscall_entry,ti_flags (%EBP)498jnz syscall_trace_entry499Cmpl $ (nr_syscalls),%eax -Jae Syscall_badsys501syscall_call:502Call *sys_call_table (,%eax,4) //Call the system to call the corresponding handler function 503syscall_after_call:504MOVL%eax,pt_eax (%ESP) # Store thereturnValue505syscall_exit:506Lockdep_sys_exit507Disable_interrupts (clbr_any) # Make sure we don'T miss an interrupt508# setting need_resched or sigpending509# between sampling and the Iret510Trace_irqs_off511MOVL ti_flags (%EBP),%ecx +Testl $_tif_allwork_mask,%ECX # current-> work//detection of current tasks 513jne syscall_exit_work //whether to jump to Syscall_exit_work to handle 514515restore_all:516Trace_irqs_iret

Let's look at the Syscall_exit_work code:

# Perform syscall exit tracing655ALIGN656 syscall_exit_work:657Testl $_tif_work_syscall_exit,%ecx658JZ work_pending //jump to signal processing, work_reached process scheduling processing, etc. 659trace_irqs_on660enable_interrupts (clbr_any) # could let Syscall_trace_leave () call661# Schedule () instead662MOVL%esp,%eax663Call Syscall_trace_leave664jmp resume_userspace665end (syscall_exit_work)

Finally, we draw a flowchart to express the execution flow of the code from System_call to Iret:

The above is my full understanding of the experiment, if there are errors, but also to correct.

Please specify the source "Linux kernel Analysis" MOOC course http://mooc.study.163.com/course/USTC-1000029000

See system calls from the kernel