Linux实验：从整体上理解进程创建、可执行文件的加载和进程执行进程切换，重点理解分析fork、execve和进程切换

学号：055
原创作品转载请注明出处 + https://github.com/mengning/linuxkernel/

实验要求

• 阅读理解task_struct数据结构http://codelab.shiyanlou.com/xref/linux-3.18.6/include/linux/sched.h#1235；
• 分析fork函数对应的内核处理过程do_fork，理解创建一个新进程如何创建和修改task_struct数据结构；
• 使用gdb跟踪分析一个fork系统调用内核处理函数do_fork ，验证您对Linux系统创建一个新进程的理解,特别关注新进程是从哪里开始执行的？为什么从那里能顺利执行下去？即执行起点与内核堆栈如何保证一致。
• 理解编译链接的过程和ELF可执行文件格式；
• 编程使用exec*库函数加载一个可执行文件，动态链接分为可执行程序装载时动态链接和运行时动态链接；
• 使用gdb跟踪分析一个execve系统调用内核处理函数do_execve ，验证您对Linux系统加载可执行程序所需处理过程的理解；
• 特别关注新的可执行程序是从哪里开始执行的？为什么execve系统调用返回后新的可执行程序能顺利执行？对于静态链接的可执行程序和动态链接的可执行程序execve系统调用返回时会有什么不同？
• 理解Linux系统中进程调度的时机，可以在内核代码中搜索schedule()函数，看都是哪里调用了schedule()，判断我们课程内容中的总结是否准确；
• 使用gdb跟踪分析一个schedule()函数 ，验证您对Linux系统进程调度与进程切换过程的理解；
• 特别关注并仔细分析switch_to中的汇编代码，理解进程上下文的切换机制，以及与中断上下文切换的关系；

实验过程

task_struct数据结构

代码量比较大，见http://codelab.shiyanlou.com/xref/linux-3.18.6/include/linux/sched.h#1235

struct task_struct {
	volatile long state;	/* -1 unrunnable, 0 runnable, >0 stopped */
	void *stack;
	atomic_t usage;
	unsigned int flags;	/* per process flags, defined below */
	unsigned int ptrace;

在操作系统中，进程是分配资源的基本单位，用PCB来描述一个进程。进程是系统进行资源分配和调度的基本单位，一个进程是一个程序的运行实例。而在Linux中，可以使用一个进程来创建另外一个进程。

do_fork()

函数源码见http://codelab.shiyanlou.com/xref/linux-3.18.6/kernel/fork.c#1623

fork、vfork和clone三个系统调用都可以创建一个新进程，都是通过调用do_fork来实现进程的创建。

p = copy_process(clone_flags, stack_start, stack_size,
1652			 child_tidptr, NULL, trace);

在do_fork()函数中，先是通过copy_process复制PCB，获得pcb指针p，初始化新进程上下文，将新进程p加入就绪队列。唤醒新进程，返回pid给父进程。

使用gdb跟踪分析一个fork系统调用内核处理函数do_fork

（1）启动qemu

cd LinuxKernel   
rm menu -rf
git clone https://github.com/mengning/menu.git
cd menu
mv test_fork.c test.c
make rootfs

开启一个新的终端，在新的终端中，输入以下命令

gdb
file linux-3.18.6/vmlinux
target remote:1234
b do_fork # 设置断点，追踪do_fork

追踪do_fork

新进程是从哪里开始执行的？

p = copy_process(clone_flags, stack_start, stack_size,
1652			 child_tidptr, NULL, trace);

在copy_process中，从copy_thread中可以看出，子进程执行的开始是ret_from_fork

int copy_thread(unsigned long clone_flags, unsigned long sp,
    unsigned long arg, struct task_struct *p)
{
    ...
    *childregs = *current_pt_regs();
    childregs->ax = 0;
    if (sp)
        childregs->sp = sp;
    p->thread.ip = (unsigned long) ret_from_fork;
    ...
}

在ret_from_fork之前，copy_thread()函数中childregs = current_pt_regs() 将父进程的regs参数赋值到子进程的内核堆栈，*childregs的类型为pt_regs，里面存放了SAVE ALL中压入栈的参数，故在之后的RESTORE ALL中能顺利执行下去。

理解编译链接的过程和ELF可执行文件格式

从源代码到可执行程序要经历以下过程：

• 预处理：涉及到宏，注释
• 编译：将c语言代码编译成汇编
• 汇编：将汇编编译成机器可执行的命令，Linux上是ELF
• 链接：将生成的目标文件和系统库文件进行链接，最终生成了可以在特定平台运行的可执行文件。

ELF：

ref：https://baike.baidu.com/item/ELF/7120560
在计算机科学中，是一种用于二进制文件、可执行文件、目标代码、共享库和核心转储格式文件。
是UNIX系统实验室（USL）作为应用程序二进制接口（Application Binary Interface，ABI）而开发和发布的，也是Linux的主要可执行文件格式。

ELF文件由4部分组成，分别是ELF头（ELF header）、程序头表（Program header table）、节（Section）和节头表（Section header table）。实际上，一个文件中不一定包含全部内容，而且他们的位置也未必如同所示这样安排，只有ELF头的位置是固定的，其余各部分的位置、大小等信息由ELF头中的各项值来决定。

编程使用exec*库函数加载一个可执行文件，动态链接分为可执行程序装载时动态链接和运行时动态链接

编写hello.c

静态链接
在编译链接时直接将需要的执行代码复制到最终可执行文件中。

动态链接
动态链接分为装载时动态链接和运行时动态链接。
动态链接库的两种链接方法：

(1) 装载时动态链接(Load-time Dynamic Linking)：这种用法的前提是在编译之前已经明确知道要调用DLL中的哪几个函数，编译时在目标文件中只保留必要的链接信息，而不含DLL函数的代码；当程序执行时，调用函数的时候利用链接信息加载DLL函数代码并在内存中将其链接入调用程序的执行空间中(全部函数加载进内存），其主要目的是便于代码共享。（动态加载程序，处在加载阶段，主要为了共享代码，共享代码内存）

(2) 运行时动态链接(Run-time Dynamic Linking)：这种方式是指在编译之前并不知道将会调用哪些DLL函数，完全是在运行过程中根据需要决定应调用哪个函数，将其加载到内存中（只加载调用的函数进内存），并标识内存地址，其他程序也可以使用该程序，并用LoadLibrary和GetProcAddress动态获得DLL函数的入口地址。（dll在内存中只存在一份，处在运行阶段）

使用gdb跟踪分析一个execve系统调用内核处理函数do_execve

int do_execve(struct filename *filename,
          const char __user *const __user *__argv,
          const char __user *const __user *__envp)
      {
          struct user_arg_ptr argv = { .ptr.native = __argv };
          struct user_arg_ptr envp = { .ptr.native = __envp };
          return do_execve_common(filename, argv, envp);
      }

调用execve()系统调用之后，再调用内核的入口sys_execve()。 sys_execve()进行一些参数的检查复制之后，调用do_execve()。 因为可执行文件不止ELF一种，还有java程序和以“#!”开始的脚本程序等， 所以do_execve()会首先检查被执行文件，读取前128个字节，特别是开头4个字节的魔数，用以判断可执行文件的格式。 如果是解释型语言的脚本，前两个字节“#!"就构成了魔数，系统一旦判断到这两个字节，就对后面的字符串进行解析，以确定程序解释器的路径。

当do_execve()读取了这128个字节的文件头部之后，然后调用search_binary_handle()去搜索和匹配合适的可执行文件装载处理过程。Linux中所有被支持的可执行文件格式都有相应的装载处理过程，search_binary_handle()会通过判断文件头部的魔数确定文件的格式，并且调用相应的装载处理过程。

理解Linux系统中进程调度的时机，可以在内核代码中搜索schedule()函数，看都是哪里调用了schedule()，判断我们课程内容中的总结是否准确

进程调度的时机

• 中断处理过程（包括时钟中断、I/O中断、系统调用和异常）中，直接调用schedule()，或者返回用户态时根据need_resched标记调用schedule()；
• 内核线程可以直接调用schedule()进行进程切换，也可以在中断处理过程中进行调度，也就是说内核线程作为一类的特殊的进程可以主动调度，也可以被动调度；
• 用户态进程无法实现主动调度，仅能通过陷入内核态后的某个时机点进行调度，即在中断处理过程中进行调度。

static void __sched __schedule(void)  
{
   struct task_struct *prev, *next;
   unsigned long *switch_count;
   struct rq *rq;
   int cpu;
need_resched:
   preempt_disable();
   cpu = smp_processor_id();  //保存当前CPU的状态在rq中
   rq = cpu_rq(cpu);
   rcu_note_context_switch(cpu);
   prev = rq->curr;  //保存当前进程current
    schedule_debug(prev); //进入这个判断函数，判断

分析switch_to中的汇编代码，理解进程上下文的切换机制，以及与中断上下文切换的关系

schedule()函数选择一个新的进程来运行，并调用context_switch进行上下文的切换，这个宏调用switch_to来进行关键上下文切换
next = pick_next_task(rq, prev);//进程调度算法都封装这个函数内部
context_switch(rq, prev, next);//进程上下文切换
switch_to利用了prev和next两个参数：prev指向当前进程，next指向被调度的进程
31#define switch_to(prev, next, last)                    \
32do {                                 \
 /*                              \
  * Context-switching clobbers all registers, so we clobber  \
  * them explicitly, via unused output variables.     \
  * (EAX and EBP is not listed because EBP is saved/restored  \
  * explicitly for wchan access and EAX is the return value of   \
  * __switch_to())                     \
  */                                \
 unsigned long ebx, ecx, edx, esi, edi;                \
                                 \
 asm volatile("pushfl\n\t"      /* save    flags */   \ 
          "pushl %%ebp\n\t"        /* save    EBP   */ \ 当前进程堆栈基址压栈
          "movl %%esp,%[prev_sp]\n\t"  /* save    ESP   */ \ 将当前进程栈顶保存prev->thread.sp
          "movl %[next_sp],%%esp\n\t"  /* restore ESP   */ \ 讲下一个进程栈顶保存到esp中
          "movl $1f,%[prev_ip]\n\t"    /* save    EIP   */ \ 保存当前进程的eip
          "pushl %[next_ip]\n\t"   /* restore EIP   */    \ 将下一个进程的eip压栈,next进程的栈顶就是他的的起点
          __switch_canary                   \
          "jmp __switch_to\n"  /* regparm call  */ \ 
          "1:\t"                        \
          "popl %%ebp\n\t"     /* restore EBP   */    \ 
          "popfl\n"         /* restore flags */  \ 开始执行下一个进程的第一条命令
                                 \
          /* output parameters */                \
          : [prev_sp] "=m" (prev->thread.sp),     \
            [prev_ip] "=m" (prev->thread.ip),        \
            "=a" (last),                 \
                                 \
            /* clobbered output registers: */     \
            "=b" (ebx), "=c" (ecx), "=d" (edx),      \
            "=S" (esi), "=D" (edi)             \
                                      \
            __switch_canary_oparam                \
                                 \
            /* input parameters: */                \
          : [next_sp]  "m" (next->thread.sp),        \
            [next_ip]  "m" (next->thread.ip),       \
                                      \
            /* regparm parameters for __switch_to(): */  \
            [prev]     "a" (prev),              \
            [next]     "d" (next)               \
                                 \
            __switch_canary_iparam                \
                                 \
          : /* reloaded segment registers */           \
         "memory");                  \
77} while (0)

通过系统调用，用户空间的应用程序就会进入内核空间，由内核代表该进程运行于内核空间，这就涉及到上下文的切换，用户空间和内核空间具有不同的地址映射，通用或专用的寄存器组，而用户空间的进程要传递很多变量、参数给内核，内核也要保存用户进程的一些寄存器、变量等，以便系统调用结束后回到用户空间继续执行，所谓的进程上下文，就是一个进程在执行的时候，CPU的所有寄存器中的值、进程的状态以及堆栈中的内容，当内核需要切换到另一个进程时，它需要保存当前进程的所有状态，即保存当前进程的进程上下文，以便再次执行该进程时，能够恢复切换时的状态，继续执行。

同理，硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理，中断上下文就可以理解为硬件传递过来的这些参数和内核需要保存的一些环境，主要是被中断的进程的环境。

Linux内核工作在进程上下文或者中断上下文。提供系统调用服务的内核代码代表发起系统调用的应用程序运行在进程上下文；另一方面，中断处理程序，异步运行在中断上下文。中断上下文和特定进程无关。