代码实现用系统调用创建进程
开发套件安装，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 (); // fork 创建新的进程
if (child_pid != 0) //根据返回 区分子父进程
return child_pid;
else {
execvp (program, arg_list); //execvp 运行一个新的程序
abort ();
}
}
createprocess.c 文件,调用上面这个函数
#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); //调用函数创建进程 执行ls
return 0;
}
编译与程序的二进制格式
文本文件通过编译生成二进制文件
在 Linux 下面，二进制的程序也要有严格的格式，这个格式我们称为 ELF（Executeable and Linkable Format，可执行与可链接格式）。这个格式可以根据编译的结果不同，分为不同的格式。
如何从文本文件编译成二进制格式的过程
编译上面的两个文件
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。
.o 里面的位置是不确定的，但是必须是可重新定位的，例如这里的 create_process 函数，将来被谁调用，在哪里调用都不清楚，有的 section，例如.rel.text, .rel.data 就与重定位有关，例如createprocess.o调用了create_process，create_process它在另外一个.o中，不知道被调函数位置只好在rel.text中标注，create_process这个函数需要重新定位
要想让 create_process 这个函数作为库文件被重用，不能以.o 的形式存在，而是要形成库文件，最简单的类型是静态链接库.a 文件（Archives），仅仅将一系列对象文件（.o）（可以有多个.o）归档为一个文件，使用命令 ar 创建。
ar cr libstaticprocess.a process.o
当有程序要使用这个静态连接库的时候，会将.o 文件提取出来，链接到程序中。
gcc -o staticcreateprocess createprocess.o -L. -lstaticprocess
-L 表示在当前目录下找.a 文件，-lstaticprocess 会自动补全文件名，比如加前缀 lib，后缀.a，变成 libstaticprocess.a，找到这个.a 文件后，将里面的 process.o 取出来，和 createprocess.o 做一个链接，形成二进制执行文件 staticcreateprocess
可执行文件
上面生成的二进制文件staticcreateprocess叫可执行文件，是 ELF 的第二种格式
和.o 文件大致相似，还是分成一个个的 section，并且被节头表描述。只不过这些 section 是多个.o 文件合并过的。在内核代码里面的定义为 struct elf32_phdr 和 struct elf64_phdr
除了有对于段的描述之外，最重要的是 p_vaddr，这个是这个段加载到内存的虚拟地址。
在 ELF 头里面，有一项 e_entry，也是个虚拟地址，是这个程序运行的入口。见上面 struct elf32_hdr 和 struct elf64_hdr
动态链接库
静态链接库一旦链接进去，代码和变量的 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）。
多了一个.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 函数在内存中真正的地址。 - GOT 怎么知道函数在内存中真正的地址呢？
对于 create_process 函数，GOT 一开始就会创建一项 GOT[y]，里面没有真正的地址，通过回调PLT告诉PLT不知道真实地址，PLT 这个时候会转而调用 PLT[0]，也即第一项，PLT[0]转而调用 GOT[2]，这里面是 ld-linux.so 的入口函数，这个函数会找到加载到内存中的 libdynamicprocess.so 里面的 create_process 函数的地址，然后把这个地址放在 GOT[y]里面。下次，PLT[x]的代理函数就能够直接调用了。
PLT就是用来放代理代码的，也即stub代码的，GOT是用来存放so对应的真实代码的地址的
ld-linux.so虽然默认会被加载，但是也是一个so，所以会放在GOT里面。要调用这个so里面的代码，也是需要从stub里面统一调用进去的，所以要回到PLT去调用。
运行程序为进程
知道了 ELF 这个格式，那怎么把这个文件加载到内存里面呢？
内核数据结构linux_binfmt，定义加载二进制文件的方法
struct linux_binfmt {
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 文件格式，linux_binfmt有对应的实现
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，06 系统调用可知 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）以数组的形式接收环境变量。
进程树
所有的进程都是从父进程 fork 过来的，其祖宗进程，这就是系统启动的 init 进程。
系统启动之后，init 进程会启动很多的 daemon 进程，为系统运行提供服务，然后就是启动 getty，让用户登录，登录后运行 shell，用户启动的进程都是通过 shell 运行的，从而形成了一棵进程树。
1 号进程是 /sbin/init，在 centOS 7 里面， ls 一下可以看到，这个进程是被软链接到 systemd
ps -ef 命令查看当前系统启动的进程
PID 1 的进程就是 init 进程 systemd，PID 2 的进程是内核线程 kthreadd，
用户态的不带中括号，内核态的带中括号。
TTY 那一列，是问号的，说明不是前台启动的，一般都是后台的服务。
一个进程从代码到二进制到运行时的过程
图右边的文件编译过程，生成 so 文件和可执行文件，放在硬盘上
图左边的用户态的进程 A 执行 fork，创建进程 B，在进程 B 的处理逻辑中，执行 exec 系列系统调用。
系统调用会通过 load_elf_binary 方法，将生成的可执行文件，加载到进程 B 的内存中执行。
参考资料：
趣谈Linux操作系统（极客时间）链接：
http://gk.link/a/10iXZ
欢迎大家来一起交流学习