写代码：用系统调用创建进程

  1.     #include <stdio.h>
  2.     #include <stdlib.h>
  3.     #include <sys/types.h>
  4.     #include <unistd.h>
  7.     extern int create_process (char* program, char** arg_list);
  10.     int create_process (char* program, char** arg_list)
  11.     {
  12.         pid_t child_pid;
  13.         child_pid = fork ();
  14.         if (child_pid != 0)
  15.             return child_pid;
  16.         else {
  17.             execvp (program, arg_list);
  18.             abort ();
  19.         }
  20.    }

fork 函数对于父进程返回子进程的进程 id，对于子进程返回零。

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

extern int create_process (char* program, char** arg_list);

int main ()
{
    char* arg_list[] = {
        "ls",
        "-l",
        "/etc/yum.repos.d/",
        NULL
    };
    create_process ("ls", arg_list);
    return 0;
}

实现了 ls 功能。

进行编译：程序的二进制格式

在 Linux 下面，二进制的程序也要有严格的格式，这个格式我们称为 ELF（Executeable and Linkable Format，可执行与可链接格式），由上述的文本文件编译而来。这个格式可以根据编译的结果不同，分为不同的格式。85320245cd80ce61e69c8391958240de.webp
编译上述的两个程序：

gcc -c -fPIC process.c
gcc -c -fPIC createprocess.c
//-fPIC参数：这个参数其实就是 Position Independent Code 的意思，也就是我们要把这个编译成一个地址无关代码（相对地址）。

在编译的时候，先做预处理工作，例如将头文件嵌入到正文中，将定义的宏展开，然后就是真正的编译过程，最终编译成为 .o 文件，这就是 ELF 的第一种类型，可重定位文件（Relocatable File）。e9c2b4c67f8784a8eec7392628ce6cd6.webp
ELF 文件的头是用于描述整个文件的。这个文件格式在内核中有定义，分别为 struct elf32_hdr 和 struct elf64_hdr。图中的每一小块叫做一个 section，也叫节。这个编译好的二进制文件里面，应该是代码，还有一些全局变量、静态变量等等。

.text：放编译好的二进制可执行代码
.data：已经初始化好的全局变量
.rodata：只读数据，例如字符串常量、const 的变量
.bss：未初始化全局变量，运行时会置 0
.symtab：符号表，记录的则是函数和变量
.strtab：字符串表、字符串常量和变量名

其中只有全局变量，因为局部变量是放在栈中的，是程序运行时随时分配空间，随时释放的，此时程序还没有启动，所以只关心全局变量保存在哪里。

这些节的元数据信息也需要有一个地方保存，就是最后的节头部表（Section Header Table）。在这个表里面，每一个 section 都有一项，在代码里面也有定义 struct elf32_shdr 和 struct elf64_shdr。在 ELF 的头里面，有描述这个文件的节头部表的位置，有多少个表项等等信息。

为啥叫可重定位呢？我们可以想象一下，这个编译好的代码和变量，将来加载到内存里面的时候，都是要加载到一定位置的。比如说，调用一个函数，其实就是跳到这个函数所在的代码位置执行；再比如修改一个全局变量，也是要到变量的位置那里去修改。但是现在这个时候，还是.o 文件，不是一个可以直接运行的程序，这里面只是部分代码片段。

有的 section，例如.rel.text, .rel.data 就与重定位有关。例如这里的 createprocess.o，里面调用了 create_process 函数，但是这个函数在另外一个.o 里面，因而 createprocess.o 里面根本不可能知道被调用函数的位置，所以只好在 rel.text 里面标注，这个函数是需要重定位的。

要想让 create_process 这个函数作为库文件被重用，不能以.o 的形式存在，而是要形成库文件，最简单的类型是静态链接库 .a 文件（Archives），仅仅将一系列对象文件（.o）归档为一个文件，使用命令 ar 创建。

ar cr libstaticprocess.a process.o

虽然这里 libstaticprocess.a 里面只有一个.o，但是实际情况可以有多个.o。当有程序要使用这个静态连接库的时候，会将.o 文件提取出来，链接到程序中。

gcc -o staticcreateprocess createprocess.o -L. -lstaticprocess

在这个命令里，-L 表示在当前目录下找.a 文件，-lstaticprocess 会自动补全文件名，比如加前缀 lib，后缀.a，变成 libstaticprocess.a，找到这个.a 文件后，将里面的 process.o 取出来，和 createprocess.o 做一个链接，形成二进制执行文件 staticcreateprocess。形成的二进制文件叫可执行文件，是 ELF 的第二种格式，格式如下：
1d8de36a58a98a53352b40efa81e9660.webp
这个格式和.o 文件大致相似，还是分成一个个的 section，并且被节头表描述。只不过这些 section 是多个.o 文件合并过的。但是这个时候，这个文件已经是马上就可以加载到内存里面执行的文件了，因而这些 section 被分成了需要加载到内存里面的代码段、数据段和不需要加载到内存里面的部分，将小的 section 合成了大的段 segment，并且在最前面加一个段头表（Segment Header Table）。在代码里面的定义为 struct elf32_phdr 和 struct elf64_phdr，这里面除了有对于段的描述之外，最重要的是 p_vaddr，这个是这个段加载到内存的虚拟地址。

在 ELF 头里面，有一项 e_entry，也是个虚拟地址，是这个程序运行的入口。当程序运行起来之后，就是下面这个样子：

# ./staticcreateprocess
# total 40
-rw-r--r--. 1 root root 1572 Oct 24 18:38 CentOS-Base.repo
......

静态链接库一旦链接进去，代码和变量的 section 都合并了，因而程序运行的时候，就不依赖于这个库是否存在。但是这样有一个缺点，就是相同的代码段，如果被多个程序使用的话，在内存里面就有多份，而且一旦静态链接库更新了，如果二进制执行文件不重新编译，也不随着更新。

因而就出现了另一种，动态链接库（Shared Libraries），不仅仅是一组对象文件的简单归档，而是多个对象文件的重新组合，可被多个程序共享。

gcc -shared -fPIC -o libdynamicprocess.so process.o

当一个动态链接库被链接到一个程序文件中的时候，最后的程序文件并不包括动态链接库中的代码，而仅仅包括对动态链接库的引用，并且不保存动态链接库的全路径，仅仅保存动态链接库的名称。

gcc -o dynamiccreateprocess createprocess.o -L. -ldynamicprocess

当运行这个程序的时候，首先寻找动态链接库，然后加载它。默认情况下，系统在 /lib 和 /usr/lib 文件夹下寻找动态链接库。如果找不到就会报错，我们可以设定 LD_LIBRARY_PATH 环境变量，程序运行时会在此环境变量指定的文件夹下寻找动态链接库。这里的 -ldynamicprocess 推测同 -lstaticprocess 作用类似。

# export LD_LIBRARY_PATH=.
# ./dynamiccreateprocess
# total 40
-rw-r--r--. 1 root root 1572 Oct 24 18:38 CentOS-Base.repo
......

<br />动态链接库，就是 ELF 的第三种类型，**共享对象文件**（Shared Object）。基于动态链接库创建出来的二进制文件格式还是 ELF，但是稍有不同。

首先，多了一个.interp 的 Segment，这里面是 ld-linux.so，这是动态链接器，也就是说，运行时的链接动作都是它做的。

另外，ELF 文件中还多了两个 section，一个是.plt，过程链接表（Procedure Linkage Table，PLT），一个是.got.plt，全局偏移量表（Global Offset Table，GOT）。

它们是怎么工作的，使得程序运行的时候，可以将 so 文件动态链接到进程空间的呢？

dynamiccreateprocess 这个程序要调用 libdynamicprocess.so 里的 create_process 函数。由于是运行时才去找，编译的时候，压根不知道这个函数在哪里，所以就在 PLT 里面建立一项 PLT[x]。这一项也是一些代码，有点像一个本地的代理，在二进制程序里面，不直接调用 create_process 函数，而是调用 PLT[x]里面的代理代码，这个代理代码会在运行的时候找真正的 create_process 函数。

找代理代码就用到了 GOT，这里面也会为 create_process 函数创建一项 GOT[y]。这一项是运行时 create_process 函数在内存中真正的地址。程序调用共享库里的 create_process 的时候，调用的是对应代理 PLT[x]，PLT[x] 再去调用GOT[y]。GOT[y] 对应的就是 create_process 在内存中的位置。

对于 create_process 函数，GOT 一开始就会创建一项 GOT[y]，但是这里面没有真正的地址，因为它也不知道，但是它有办法，它又回调 PLT，告诉它，你里面的代理代码来找我要 create_process 函数的真实地址，我不知道，你想想办法吧。

PLT 这个时候会转而调用 PLT[0]，也即第一项，PLT[0]转而调用 GOT[2]，这里面是 ld-linux.so 的入口函数，这个函数会找到加载到内存中的 libdynamicprocess.so 里面的 create_process 函数的地址，然后把这个地址放在 GOT[y]里面。下次，PLT[x]的代理函数就能够直接调用了。

整个过程复杂而又巧妙。

运行程序为进程

知道了 ELF 这个格式，这个时候它还是个程序，那怎么把这个文件加载到内存里面呢？在内核中，有这样一个数据结构，用来定义加载二进制文件的方法。

struct linux_binfmt {
        struct list_head lh;
        struct module *module;
        int (*load_binary)(struct linux_binprm *);
        int (*load_shlib)(struct file *);
        //指向返回值为 int 类型的函数的指针，后边是参数
        int (*core_dump)(struct coredump_params *cprm);
        unsigned long min_coredump;     /* minimal dump size */
} __randomize_layout;

对于 ELF 文件格式，有对应的实现。

static struct linux_binfmt elf_format = {
        .module         = THIS_MODULE,
        .load_binary    = load_elf_binary,
        .load_shlib     = load_elf_library,
        .core_dump      = elf_core_dump,
        .min_coredump   = ELF_EXEC_PAGESIZE,
};

其中函数 load_elf_binary 在加载内核镜像的时候也被调用，具体过程：do_execve->do_execveat_common->exec_binprm->search_binary_handler。

那 do_execve 又是被谁调用的呢？我们看下面的代码。

SYSCALL_DEFINE3(execve,
    const char __user *, filename,
    const char __user *const __user *, argv,
    const char __user *const __user *, envp)
{
  return do_execve(getname(filename), argv, envp);
}

结合系统调用一节就可以发现，exec 这个系统调用最终调用的正是 load_elf_binary。exec 比较特殊，它是一组函数：

包含 p 的函数（execvp, execlp）会在 PATH 路径下面寻找程序；
不包含 p 的函数需要输入程序的全路径；
包含 v 的函数（execv, execvp, execve）以数组的形式接收参数；
包含 l 的函数（execl, execlp, execle）以列表的形式接收参数；
包含 e 的函数（execve, execle）以数组的形式接收环境变量。465b740b86ccc6ad3f8e38de25336bf6.webp
在上面 process.c 的代码中，我们创建 ls 进程，也是通过 exec。

进程树

既然所有的进程都是从父进程 fork 过来的，那总归有一个祖宗进程，这就是咱们系统启动的 init 进程。
4de740c10670a92bbaa58348e66b7b16.webp
在解析 Linux 的启动过程的时候，1 号进程是 /sbin/init。如果在 centOS 7 里面，我们 ls 一下，可以看到，这个进程是被软链接到 systemd 的。

ls /sbin/init -l
lrwxrwxrwx 1 root root 22 Dec 22 04:08 /sbin/init -> ../lib/systemd/systemd

系统启动之后，init 进程会启动很多的 daemon 进程，为系统运行提供服务，然后就是启动 getty，让用户登录，登录后运行 shell，用户启动的进程都是通过 shell 运行的，从而形成了一棵进程树。

我们可以通过 ps -ef 命令查看当前系统启动的进程，我们会发现有三类进程。

[root@VM-24-5-centos ~]# ps -ef
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 Apr30 ?        00:00:36 /usr/lib/systemd/systemd --switched-root --systeroot           2       0  0 Apr30 ?        00:00:00 [kthreadd]
root           3       2  0 Apr30 ?        00:00:00 [rcu_gp]
root           4       2  0 Apr30 ?        00:00:00 [rcu_par_gp]
......
root         498       2  0 Apr30 ?        00:00:00 [scsi_eh_1]
root         499       2  0 Apr30 ?        00:00:00 [scsi_tmf_1]
root         532       2  0 Apr30 ?        00:00:02 [jbd2/vda1-8]
root         533       2  0 Apr30 ?        00:00:00 [ext4-rsv-conver]
root         642       1  0 Apr30 ?        00:00:10 /usr/lib/systemd/systemd-journald
root         672       1  0 Apr30 ?        00:00:00 /usr/lib/systemd/systemd-udevd
......
root      293884  293849  0 10:18 ?        00:00:00 sshd: root@pts/0
root      293885  293884  0 10:18 pts/0    00:00:00 -bash
root      294590    1192  0 10:22 ?        00:00:00 sleep 60
root      294618  293885  0 10:22 pts/0    00:00:00 ps -ef

PID 1 的进程就是我们的 init 进程 systemd，PID 2 的进程是内核线程 kthreadd，这两个我们在内核启动的时候都见过。其中用户态的不带中括号，内核态的带中括号。

接下来进程号依次增大，可以看到所有带中括号的内核态的进程，祖先都是 2 号进程。而用户态的进程，祖先都是 1 号进程。tty 那一列，是问号的，说明不是前台启动的，一般都是后台的服务。

pts 的父进程是 sshd，bash 的父进程是 pts，ps -ef 这个命令的父进程是 bash。这样整个链条都比较清晰了。

总结

这一节我们介绍了一个进程从代码到二进制到运行时的一个过程，我们用一个图总结一下。我们首先通过图右边的文件编译过程，生成 so 文件和可执行文件，放在硬盘上。下图左边的用户态的进程 A 执行 fork，创建进程 B，在进程 B 的处理逻辑中，执行 exec 系列系统调用。这个系统调用会通过 load_elf_binary 方法，将刚才生成的可执行文件，加载到进程 B 的内存中执行。
dbd8785da6c3ce3fe1abb7bb5934b7a9.webp

  • 写代码
  • 编译成 ELF 格式的二进制文件, 有三种格式(可重定位 .o 文件; 可执行文件; 共享对象文件 .so)
  • 可重定位 .o 文件(ELF 第一种格式)
    • .h + .c 文件, 编译得到可重定位 .o 文件
    • .o 文件由: ELF 头, 多个节(section), 节头部表组成(每个节有一项纪录); 节表的位置和纪录数由 ELF 头给出.
    • .o 文件只是程序部分代码片段
    • .rel.text 和 .rel.data 标注了哪些函数/数据需要重定位
    • 要函数可被调用, 要以库文件的形式存在, 最简单是创建静态链接库 .a 文件(Archives)
    • 通过 ar 创建静态链接库, 通过 gcc 提取库文件中的 .o 文件, 链接到程序中
    • 链接合并后, 就可以定位到函数/数据的位置, 形成可执行文件
  • 可执行文件(ELF 第二种格式)
    • 链接合并后, 形成可执行文件
    • 同样包含: ELF 头, 多个节, 节头部表; 另外还有段头表(包含段的描述, p_vaddr 段加载到内存的虚拟地址)
    • ELF 头中有 e_entry , 指向程序入口的虚拟地址
  • 共享对象 .so 文件(ELF 第三种格式)
    • 静态链接库合并进可执行文件, 内存浪费，不能及时更新
    • 动态链接库-链接了动态链接库的程序, 仅包含对该库的引用(且只保存名称)
    • 通过 gcc 创建, 通过 gcc 链接
    • 运行时, 先找到动态链接库(默认在 /lib 和 /usr/lib 找)，也可以自定义
    • 增加了 .interp 段, 里面是 ld_linux.so (动态链接器)
    • 增加了两个节 .plt(过程链接表)和 .got.plt(全局偏移表)
    • 一个动态链接函数对应 plt 中的一项 plt[x], plt[x] 中是代理代码, 调用 got 中的一项 got[y]
    • 起始, got 没有动态链接函数的地址, 都指向 plt[0], plt[0] 又调用 got[2], got[2]指向 ld_linux.so
    • ld_linux.so 找到加载到内存的动态链接函数的地址, 并将地址存入 got[y]
  • 加载 ELF 文件到内存
    • 通过系统调用 exec 调用 load_elf_binary
    • exec 是一组函数
      • 包含 p: 在 PATH 中找程序
      • 不包含 p: 需提供全路径
      • 包含 v: 以数字接收参数
      • 包含 l: 以列表接收参数
      • 包含 e: 以数字接收环境变量
  • 进程树
    • ps -ef: 用户进程不带中括号, 内核进程带中括号
    • 用户进程祖先(1号进程, systemd); 内核进程祖先(2号进程, kthreadd)
    • tty ? 一般表示后台服务