Experiment three: Tracking and analyzing the boot process of the Linux kernel

The process of building menuos under Ubuntu 16.04:

1. Download kernel source code compile kernel

1 # Download kernel source code compile Kernel 2 cd ~/LINUXKERNEL/3 wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.6.tar.xz 4 xz-d linux- 3.18.6.TAR.XZ 5 TAR-XVF Linux-3.18.6.tar 6 CD linux-3.18.6 7 make I386_defconfig 8 do # usually compiles for a long time, less 20 minutes more hours 9  10 # Make root filesystem one CD ~/linuxkernel/12 mkdir rootfs13 git clone https://github.com/mengning/menu.git  # If you are wall, you can use attachments Menu.zip CD menu15 gcc-o init linktable.c menu.c test.c-m32-static-lpthread16 CD. /ROOTFS17 CP. /menu/init./18 Find. | Cpio-o-HNEWC |gzip-9 >. /rootfs.img19  20 # Boot menuos system CD ~/LINUXKERNEL/22 Qemu-kernel LINUX-3.18.6/ARCH/X86/BOOT/BZIMAGE-INITRD Rootfs.img

2. Reconfigure and compile Linux to carry the debug information

1 $ sudo apt-get install Ncurses-dev 2  3 First you need to install the graphical debugging tool Ncurses,ncurses-dev is a library that can be used to display graphical control pages. 4  5 $ make Menuconfig 6  7 Select kernelhacking-> 8  9 Select Comile-time checks and Comp[iler options->10 11 press Y to select C Ompile the kernel with debug info12 13 save Exit 14 15 re-make

3. Using GDB to trace the debug kernel

1 Qemu-kernel linux-3.18.6/arch/x86/boot/bzimage-initrd Rootfs.img-s-S # Description of the-s and-s options: 2 #-S freeze CPU at startup (US E ' C ' to start execution) 3 #-S shorthand for-gdb tcp::1234 If you do not want to use 1234 ports, you can use-GDB tcp:xxxx to replace-s Option 4 5 open a Shell window 6 gdb7 (g db) file Linux-3.18.6/vmlinux # before Targe remote in the GDB interface load symbol table 8 (GDB) Target remote:1234 # Establish a connection between GDB and Gdbserver, press C Let the Linux on Qemu continue to run 9 (gdb) Break Start_kernel # breakpoints can be set before target remote or after

You can then proceed to the list and look down, or step-step, or use the sink-coded ni (next instruction) to run the debugs on a per-instruction basis.

Some of the commonly used GDB commands:

(GDB) Break N: Set breakpoint at Nth row

(GDB) R: Run the Program

(GDB) N: Single Step execution

(GDB) C: Continue running

(GDB) p variable: The value of the print variable

(GDB) bt: View the function stack

(GDB) Set args parameter: specifying the parameters at run time

(GDB) Show args: View Set parameters

(GDB) Delete breakpoint number n: Delete nth Breakpoint

(GDB) Step: Single-step debugging, if there is a function call, then enter the function (unlike the command n, N is not into the function of the call)

The basic work is these, I try to analyze the kernel from the Start_kernel to the INIT process to start the general process

Use the list command to see the Start_kernel source code:

Lockdep_init (): Linux has a deadlock detection module LOCKDEP, see the comment is the initialization of the hash table, should be the kernel will rely on this table to do other things.

Set_task_stack_end_magic (&init_task): Init_task is a global variable, which is a manually created PCB. It is initialized in Linux/init/init_task.c. The specific code is

struct Task_struct init_task = Init_task (Init_task); Then task_struct should be a structure similar to the PCB structure, and init_task is the function that initializes the struct.

The following is the initialization of some modules, the level of a limited number of explanations, just say the teacher mentioned function bar.

Trap_init (): Initializes the interrupt vector and sets some of the interrupt gates.

Mm_init (): Initialization of the memory management module.

Sched_init (): Initialization of the dispatch module.

Rest_init (): The source code is as follows:

StaticNoinlinevoid__init_refok Rest_init(void)394{395IntPID;396 397         rcu_scheduler_starting();398/*399* We need to spawn Init first so it obtains PID 1, however -* The INIT task would end up wanting to create kthreads, which, if401* We schedule it before we create Kthreadd, would OOPS.402*/403         Kernel_thread(Kernel_init,NULL,Clone_fs);404         Numa_default_policy();405         PID=Kernel_thread(Kthreadd,NULL,Clone_fs|Clone_files);406         Rcu_read_lock();407         Kthreadd_task=Find_task_by_pid_ns(PID, &Init_pid_ns);408         Rcu_read_unlock();409          Complete(&kthreadd_done);410 411/*412* The boot idle thread must execute schedule ()413* At least once to get things moving:414*/415         Init_idle_bootup_task( Current);416         schedule_preempt_disabled();417/* Call to Cpu_idle with preempt disabled */418         Cpu_startup_entry(Cpuhp_online);419}

Starting with  Rest_init, Linux began to produce a process, because Init_task is statically manufactured, Pid=0, which attempts to incorporate execution from the earliest assembly code until start_kernel into the context of the init_task process. 

There is a run_init_process function in the Kernel_init function of line No. 403, which is to establish the init_process process, which is the 1th process in the Linux system. It is the first user-state process.
And from the last cpu_startup_entry can see Init_task later became an idle process, that is, process No. 0, when the system does not run, the idle process has been running.



Summarize:
Through this experiment, I have a general understanding of the Liunx kernel boot process.
When the kernel starts, it initializes some of the hardware, which is done in assembly language, and then runs Start_kernel, the C-language part of the kernel. Start_kernel will continue with some kernel initialization to establish process number No. 0.
, and finally set up process 1th through Rest_init (), that is, the first user-state process, and the later process No. 0 becomes an idle process, and when no other process runs, the system runs process No. 0.
Generally speaking, although understand the general process, but still feel the understanding of the kernel is just floating on the superficial surface, as if to understand something, and as if do not understand. I hope to continue in-depth study can answer my doubts. At the same time also encourage each other it.

Baojian Original works reproduced please specify the source "Linux kernel Analysis" MOOC course http://mooc.study.163.com/course/USTC-1000029000

Experiment three: Tracking and analyzing the boot process of the Linux kernel