2019-2020-1 20199314 "Linux kernel principle and Analysis" in the seventh week of work

gdb trace debugging process description and create

First, the description of the process - the broad outline
1.1 memory management, file system, inter-process communication signals and string together the concepts and content.

  • Process control block -PCB.

  • Process descriptor

1.2 Data structure struct task_struct

Sample code:

Structure contains a lot of various documents such as the process control state process state, stack stack structure diagram below.

1.3 Linux process status
Linux operating system, process status and process status is very different between the two.

  • Runnable
  • Ready state
  • Clogged states

FIG relationship between the three:

The Linux TASK_RUNNING both may be in another state might be ready to run state, and this principle in different operating systems, and the reason is the Linux kernel TASK_RUNNING states only that it is possible to obtain control over the CPU, once it is operational state, did not get the ready state is scheduled in the state.

Process identifier:

pid_t pid;
pid-t tpid;

Doubly linked list:

struct list_head tasks;
struct list_head{
    strcut list_head *next,*prev;
}

Diagram is as follows:

The relationship between father and his sons create 1.4 processes

Parent --real_parent, parent
child process --struct list_head children
Brotherhood process --struct list_head sibling

Diagram is as follows:

experiment procedure

This week's experiment not only understand the process of creation also need to track the process of analyzing the process of creating.

Following the formal start of the experimental procedure

Execute the following code:

ls
cd ~/LinuxKernel
rm menu -rf
git clone https://github.com/mengning/menu.git
cd menu 
mv test_fork.c test.c
make rootfs  //主要功能在于编译增加了fork文件

Run shot:

After a while qemu window to complete the compilation process is executed:

Enter the command fork several times to see whether a successful call:

Gdb debugging kernel ready to start tracking program:

Load the kernel and port:

 file linux-3.18.6/vmlinux
 target remote:1234

Set a breakpoint kernel function in the Linux kernel:

b sys_clone
b do_fork
b dup_task_struct
b copy_process
b copy_thread
b ret_from_fork

Continue running kernel, enter c in the line of code, you will find the first breakpoint do_fork settings. :

Stepping through the input n or s (It is noted that a function of performing the source n will invoke execution of an execution, and s is not).

Continue to find the few remaining breakpoints to track.

to sum up:

At first I intend to experiment on their own virtual machine, although the 3.9.4 kernel with their own experiments and upstairs is not the same, but essentially should still be no problem, the problem may be altered kernel before it, nor clear. So we had to continue with the environment at every turn crash laboratory building. Tucao about just a few lines of code to run to the last step when he got stuck.

ls
cd ~/LinuxKernel
rm menu -rf
git clone https://github.com/mengning/menu.git
cd menu 
mv test_fork.c test.c
make rootfs
qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -S -s

May be simultaneously open two cores pages for him too much pressure on it. Every experimental environment can only delete the code re-knock, I spent a lot of time.

Guess you like

Origin www.cnblogs.com/morvalhe/p/11780604.html