一 、可执行程序的装载
1. 预处理、编译、链接
gcc –e –o hello.cpp hello.c //预处理
gcc -x cpp-output -S -o hello.s hello.cpp //编译
gcc -x assembler -c hello.s -o hello.o-m32 //汇编
gcc -o hello hello.o //链接成可执行文件，使用共享库
用gcc -o hello.static hello.o -static静态编译出来的hello.static把C库里需要的东西也放到可执行文件里了。用命令ls –l，可以看到hello只有7K，hello.static有大概700K。
2. ELF文件
ELF（Excutable and Linking Format）是一个文件格式的标准。通过readelf-h hello查看可执行文件hello的头部（-a查看全部信息，-h只查看头部信息），头部里面注明了目标文件类型ELF32。Entry point address是程序入口，地址为0x8048310,
即可执行文件加载到内存中开始执行的第一行代码地址。头部后还有一些代码数据等等。可执行文件的格式和进程的地址空间有一个映射的关系，当程序要加载到内存中运行时，将ELF文件的代码段和数据段加载到进程的地址空间。
ELF文件里面三种目标文件：可重定位（relocatable）文件保存着代码和适当的数据，用来和其它的object文件一起来创建一个可执行文件或者是一个共享文件（主要是.o文件）；可执行（executable）文件保存着一个用来执行的程序，该文件指出了exec(BA_OS)如何来创建程序进程映象（操作系统怎么样把可执行文件加载起来并且从哪里开始执行）；共享object文件保存着代码和合适的数据，用来被两个链接器链接。第一个是链接编辑器（静态链接），可以和其它的可重定位和共享object文件来创建其它的object。第二个是动态链接器，联合一个可执行文件和其它的共享object文件来创建一个进程映象。
3. 动态链接
动态链接有可执行装载时的动态链接（大多数）和运行时的动态链两种方式。
（1）共享库
shlibexample.h中定义了SharedLibApi()函数，shlibexample.c是对此函数的实现。用gcc -shared shlibexample.c -o libdllibexample.so（在64位环境下执行时加上-32）生成.so文件。这样就生成了共享库文件。
#include <stdio.h>
#include "shlibexample.h"
int SharedLibApi()
{
printf("This is a shared libary!\n");
return SUCCESS;
}（2）动态加载共享库
dllibexample.h定义了DynamicalLoadingLibApi()函数，dllibexample.c是对此函数的实现。同样使用gcc -shared dllibexample.c -o libdllibexample.so 得到动态加载共享库。
#include <stdio.h>
#include "dllibexample.h"
#define SUCCESS 0
#define FAILURE (-1)
int DynamicalLoadingLibApi()
{
printf("This is a Dynamical Loading libary!\n");
return SUCCESS;
}（3）main函数使用两种动态链接库。
#include <stdio.h>
#include "shlibexample.h"
#include <dlfcn.h>
int main()
{
printf("This is a Main program!\n");
/* Use Shared Lib */
printf("Calling SharedLibApi() function of libshlibexample.so!\n");
SharedLibApi(); //直接调用共享库
/* Use Dynamical Loading Lib */
void * handle = dlopen("libdllibexample.so",RTLD_NOW);//打开动态库并将其加载到内存
if(handle == NULL)
{
printf("Open Lib libdllibexample.so Error:%s\n",dlerror());
return FAILURE;
}
int (*func)(void);
char * error;
func = dlsym(handle,"DynamicalLoadingLibApi");
if((error = dlerror()) != NULL)
{
printf("DynamicalLoadingLibApi not found:%s\n",error);
return FAILURE;
}
printf("Calling DynamicalLoadingLibApi() function of libdllibexample.so!\n");
func();
dlclose(handle); //卸载库
return SUCCESS;
}可以看到main函数中只include了shlibexample（共享库），没有include dllibexample（动态加载共享库），但是include了dlfcn。因为前面加了共享库的接口文件，所以可以直接调用共享库。但是如果要调用动态加载共享库，就要使用定义在dlfcn.h中的dlopen。
用gcc main.c -o main -L/path/to/your/dir -lshlibexample -ldl -m32 生成可执行文件。注意，这里只提供shlibexample的-L，并没有提供dllibexample的相关信息，只是指明了-ldl。-dl动态加载，编译main.c的时候，没有指明任何相关信息，只是在程序内部指明了。实验截图如下：
3. 代码分析
当前的可执行程序在执行，执行到execve的时候陷入到内核态，用execve的加载的可执行文件把当前进程的可执行程序给覆盖掉，当execve的系统调用返回的时候，已经返回的不是原来的那个可执行程序了，是新的可执行程序的起点（main函数）。shell环境会执行execve，把命令行参数和环境变量都加载进来，当系统调用陷入到内核里面的时候，system call调用sys_execve。sys_execve中调用了do_execve。
//sys_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);
}
//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);
}很明显，继续分析其中调用的do_execve_common：
static int do_execve_common(struct filename *filename,
struct user_arg_ptr argv,
struct user_arg_ptr envp)
{
struct linux_binprm *bprm;
struct file *file;
struct files_struct *displaced;
int retval;
...
bprm = kzalloc(sizeof(*bprm), GFP_KERNEL);//在堆上分配一个linux_binprm结构体
...
file = do_open_exec(filename);//打开需要加载的可执行文件，file中就包含了打开的可执行文件的信息
...
bprm->file = file; //赋值file指针
bprm->filename = bprm->interp = filename->name;//赋值文件名
retval = bprm_mm_init(bprm); //创建进程的内存地址空间
...
bprm->argc = count(argv, MAX_ARG_STRINGS);//赋值参数个数
...
bprm->envc = count(envp, MAX_ARG_STRINGS);//赋值环境变量个数
...
retval = copy_strings_kernel(1, &bprm->filename, bprm); //从内核空间获取文件路径；
...
bprm->exec = bprm->p; //p为当前内存页最高地址
retval = copy_strings(bprm->envc, envp, bprm);//把环境变量拷贝到bprm中
...
retval = copy_strings(bprm->argc, argv, bprm);//把命令行参数拷贝到bprm中
...
retval = exec_binprm(bprm);//处理可执行文件
...
return retval;
}linux_binprm结构体用来保存要执行文件的相关信息, 如文件的头128字节、文件名、命令行参数、环境变量、文件路径、内存描述符信息等。exec_binprm函数保存当前的pid，其中ret = search_binary_handler(bprm); 调用 search_binary_handler 寻找可执行文件的相应处理函数。
int search_binary_handler(struct linux_binprm *bprm)
{
bool need_retry = IS_ENABLED(CONFIG_MODULES);
struct linux_binfmt *fmt;
int retval;
...
read_lock(&binfmt_lock);
list_for_each_entry(fmt, &formats, lh) { //遍历文件解析链表
if (!try_module_get(fmt->module))
continue;
read_unlock(&binfmt_lock);
bprm->recursion_depth++;
//解析elf格式执行的位置
retval = fmt->load_binary(bprm);// 加载可执行文件的处理函数
read_lock(&binfmt_lock);
...
}
return retval;linux_binfmt结构体定义了一些函数指针，不同的Linux可接受的目标文件格式（如load_binary，load_shlib，core_dump）采用不同的函数来进行目标文件的装载。每一个linux_binfmt结构体对应一种二进制程序处理方法。这些结构体实例会通过init_elf_binfmt以注册的方式加入到内核对应的format链表中去，通过register_binfmt()和unregister_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);//在core文件中保存当前进程的上下文
unsigned long min_coredump;
};目标文件的格式是ELF，所以retval = fmt->load_binary(bprm);中load_binary实际上调用load_elf_binary完成ELF二进制映像的认领、装入和启动。load_elf_binary这个函数指针被包含在一个名为elf_format的结构体中：
static structlinux_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,
}; 全局变量elf_format赋给了一个指针，在init_elf_binfmt里把变量注册注册到文件解析链表中，就可以在链表里找到相应的文件格式。继续分析load_elf_binary：
static int load_elf_binary(struct linux_binprm *bprm)
{
...
if (elf_interpreter) { // 动态链接的处理
...
} else { // 静态链接的处理
elf_entry =loc->elf_ex.e_entry;
...
}
}
...
//将ELF文件映射到进程空间中，execve系统调用返回用户态后进程就拥有了新的代码段、数据段。
current->mm->end_code = end_code;
current->mm->start_code =start_code;
current->mm->start_data =start_data;
current->mm->end_data = end_data;
current->mm->start_stack =bprm->p;
...
start_thread(regs, elf_entry, bprm->p);
}ELF文件中的Entry point address字段指明了程序入口地址，这个地址一般是0x8048000（0x8048000以上的是内核段内存）。该入口地址被解析后存放在elf_ex.e_entry中，所以静态链接程序的起始位置就是elf_entry。这个函数中还有一个关键点start_thread：
start_thread(struct pt_regs *regs, unsigned long new_ip, unsigned long new_sp)
{
set_user_gs(regs, 0);
regs->fs = 0;
regs->ds = __USER_DS;
regs->es = __USER_DS;
regs->ss = __USER_DS;
regs->cs = __USER_CS;
regs->ip = new_ip;
regs->sp = new_sp;
regs->flags = X86_EFLAGS_IF;
set_thread_flag(TIF_NOTIFY_RESUME);
}regs中为系统调用时SAVE_ALL宏压入内核栈的部分。new_ip的值等于参数elf_entry的值，即把ELF文件中定义的main函数起始地址赋值给eip寄存器，进程返回到用户态时的执行位置从原来的int 0x80的下一条指令变成了new_ip的位置。
总结一下，调用顺序是sys_execve -> do_execve -> do_execve_common -> exec_binprm，当系统调用从内核态返回到用户态时，eip直接跳转到ELF程序的入口地址，CPU也得到新的用户态堆栈（包含新程序的命令行参数和shell上下文环境）。这样，新程序就开始执行了。
4.静态链接可执行文件的调试
用test_exe.c覆盖test.c，增加了一句MenuConfig（）语句，并且qemu中增加了exec指令。
然后开始跟踪分析一个execve系统调用内核处理函数：
cd ..
qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -S -s
打开一个新shell，调试
gdb
file linux-3.18.6/vmlinux
target remote:1234
b sys_execve
b load_elf_binary
c
二 、总结
本周我学习了exec()函数的结构，对此进行了查看和分析。
由以上代码可知，do_ execve调用了do_ execve_ common，而do_ execve_ common又主要依靠了exec_ binprm，在exec_ binprm中又有一个至关重要的函数，叫做search_binary_ handler。这就是sys_execve的内部处理过程。 而本周学习的重点就是，文件处理的过程：
预处理：gcc –E –o hello.cpp hello.c -m32 （负责把include的文件包含进来，宏替换）
编 译：gcc -x cpp-output –S hello.s –o hello.cpp -m32（gcc –S调用ccl,编译成汇编代码）
汇 编：gcc -x assembler –c hello.s –o hello.o; （gcc -c 调用as,得到二进制文件）
链 接：gcc –o hello hello.o ;gcc -o （调用ld形成目标可执行文件）
链接分为静态链接和动态链接。静态链接生成三种主要ELF目标文件:
1.可重定位文件：保存代码和适当的数据，用来和其他object文件一起创建一个可执行文件或一个共享文件。主要是.o文件。
2.可执行文件：保存一个用来执行的程序，指出了exec(BA_OS)如何来创建程序进程映象，怎么把文件加载出来以及从哪里开始执行。
3.共享文件：保存着代码和数据用来被以下两个链接器链接。
一是链接编译器，可以和其他的可重定位和共享文件创建其他的object文件；
二是动态链接器，联合一个可执行文件和其他 共享文件来创建一个进程映象。主要是.so文件。
eip也是一个重要的概念，对于eip，如果是静态链接的可执行文件，那么eip指向该elf文件的文件头e_entry所指的入口地址；
如果是动态链接，eip指向动态链接器。而对于execve执行静态链接程序时，通过修改内核堆栈中保存的eip的值作为新进程的起点。
1378
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
