10 | 进程：公司接这么多项目，如何管？

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。

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

有了系统调用就可以创建进程了。

Linux写程序和编译程序也需要一系列的开发套件，类似vs一样。

yum -y groupinstall "Development Tools"

process.c 用一个函数封装通用的创建进程的逻辑：

    #include <stdio.h>
    #include <stdlib.h>
    #include <sys/types.h>
    #include <unistd.h>
    
    
    extern int create_process (char* program, char** arg_list);
    
    
    int create_process (char* program, char** arg_list)
    {
        pid_t child_pid;
        child_pid = fork ();
        if (child_pid != 0)
            return child_pid;
        else {
            execvp (program, arg_list);
            abort ();
        }
   }

用到了fork 系统调用，根据fork 的返回值不同，父进程和子进程就此分道扬镳了，子进程里面，通过 execvp 运行一个新程序。

创建第二个文件，调用上面的函数：

#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 。

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

文本里的内容只有人能看懂，CPU不能执行里面的指令，CPU只能认识二进制的，“0101” 这种。指令翻译成CPU能认识的话的过程就是编译（Compile），编译好的文件（项目执行计划书）才是CPU可以真正执行的。

项目执行计划书要有一定的规范，统一的格式，这样才能保证无论交给谁，按照里面的指令执行，达到预期的效果。

Linux 下面二进制的程序也要有严格的格式，称为ELF（Executeable and Linkable Format，可执行与可链接格式） ，这个格式可以根据编译结果的不同，分为不同的格式。

---

下面是介绍如何从文本文件编译成二进制格式的：

上面的代码中，include 的部分是头文件，我们写的 .c 结尾的是源文件。

开始编译：

gcc -c -fPIC process.c
gcc -c -fPIC createprocess.c

在编译的时候，先做预处理工作，例如：将头文件嵌入到正文中，将定义的宏展开，然后是真正的编译过程，最终编译成 .o 文件，这就是ELF的第一种类型 可重定位文件（Relocatable File） 。

这个文件的格式是这样的：

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 文件，不是一个可以直接运行的程序，这里面只是部分代码片段。

例如这里面的 create_process 函数，将来被谁调用在哪里调用都不知道，更别提确定位置了。 所以 .o 里面的位置是不确定的，但是必须是可重新定位的，因为以后用来做函数库，搬到哪里就重新定位这些代码，变量的位置。

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

静态链接库 .a 文件（Archives）：想让create_process 函数作为库文件被重用，行成最简单的库文件。

将一系列对象文件 (.o) 归档为一个文件，使用命令 ar 创建。如下只有一个.o，实际可有多个

ar cr libstaticprocess.a process.o

当有程序使用这个静态链接库时，会将.o文件提取出来，链接到程序中：
-L. 当前目录下找.a 文件；
-lstaticprocess 会自动补全文件名，比如加前缀lib，后缀.a 变成libstaticprocess.a，找到这个.a 文件后，将里面的process.o 取出来，和createprocess.o 做一个链接，形成二进制执行文件 staticcreateprocess 。

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

二进制，也叫可执行文件。是ELF 的第二种格式，格式如下：

这个格式和.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 环境变量，程序运行时会在此环境变量指定的文件夹下寻找动态链接库。

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

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

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

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

它们的工作过程如下：
dynamiccreateprocess 这个程序要调用 libdynamicprocess.so 里的 create_process 函数。

在运行的时候才去找，因此编译的时候，不知道函数在哪里，在PLT 里面建立一项 PLT[x] ，这一项也是一些代码，有点像一个本地代理，在二进制程序里面，不直接调用 create_process 函数，而是调用 PLT[X] 里面的代理代码，这个代理代码会在运行的时候找真正的 create_process 函数。

使用 GOT 来找到代理代码，GOT里面会为 create_process 函数创建一项 GOT[y] 调用的就是加载到内存中的 libdynamicprocess.so 里面的 create_process 函数了。

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

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

运行程序为进程

ELF 还是个程序，如何加载到内存中。

内核中，有如下的数据结构，用来定义加载二进制文件的方法：

        struct list_head lh;
        struct module *module;
        int (*load_binary)(struct linux_binprm *);
        int (*load_shlib)(struct file *);
        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 ，加载内核镜像的时候，用的也是这种格式。

调用 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）：以数组的形式接收环境变量

在上面 process.c 代码中，我们创建 ls进程，也是通过 exec。

进程树

既然所有的进程都是从父进程 fork 过来的，就有个祖宗进程。
系统启动的 init 进程就是祖宗进程。

1 号进程是 /sbin/init ，如果在centos7里面，查看是软连接到 systemd 的

/sbin/init -> ../lib/systemd/systemd

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

ps -ef 查看当前系统启动的进程，有三类进程：

[root@deployer ~]# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0  2018 ?        00:00:29 /usr/lib/systemd/systemd --system --deserialize 21
root         2     0  0  2018 ?        00:00:00 [kthreadd]
root         3     2  0  2018 ?        00:00:00 [ksoftirqd/0]
root         5     2  0  2018 ?        00:00:00 [kworker/0:0H]
root         9     2  0  2018 ?        00:00:40 [rcu_sched]
......
root       337     2  0  2018 ?        00:00:01 [kworker/3:1H]
root       380     1  0  2018 ?        00:00:00 /usr/lib/systemd/systemd-udevd
root       415     1  0  2018 ?        00:00:01 /sbin/auditd
root       498     1  0  2018 ?        00:00:03 /usr/lib/systemd/systemd-logind
......
root       852     1  0  2018 ?        00:06:25 /usr/sbin/rsyslogd -n
root      2580     1  0  2018 ?        00:00:00 /usr/sbin/sshd -D
root     29058     2  0 Jan03 ?        00:00:01 [kworker/1:2]
root     29672     2  0 Jan04 ?        00:00:09 [kworker/2:1]
root     30467     1  0 Jan06 ?        00:00:00 /usr/sbin/crond -n
root     31574     2  0 Jan08 ?        00:00:01 [kworker/u128:2]
......
root     32792  2580  0 Jan10 ?        00:00:00 sshd: root@pts/0
root     32794 32792  0 Jan10 pts/0    00:00:00 -bash
root     32901 32794  0 00:01 pts/0    00:00:00 ps -ef

PID 1 的进程就是 init 进程 systemd，
PID2 的进程是内核线程 kthreadd

用户态的不带中括号；内核态的带中括号。

接下来进程号依次增大，所有带中括号的内核态的进程，祖先都是2号进程。
用户态的进程，祖先都是1号进程。

tty 问号说明，一般不是前台启动的，是后台的服务。

ps -ef 这个命令的父进程是bash；bash的父进程是pts；pts的父进程是 sshd。

总结时刻

用一个图总结下：一个进程从代码到二进制到运行时的一个过程。

1、通过图右边的文件编译过程，生成so文件和可执行文件，放在硬盘上。
2、图左边的用户态的进程A 执行 fork，创建进程B ，在进程B的处理逻辑中，执行exec 系列系统调用。 这个系统调用会通过 load_elf_binary 方法，将刚才生成的可执行文件，加载到进程B 的内存中执行。

---

readelf 工具用于分析ELF的信息；
objdump 工具用来显示二进制文件的信息；
hexdump工具用来查看文件的十六进制编码；
nm 工具用来显示指定文件中符号的信息。
可以用这些工具，分析生成的.o 和 .so 和可执行文件。