Linux 动态函式库解析(四)

　　程序启动的流程

　　在 linux 的环境中最常见的可执行档的种类包括了 Script 档、Aout 格式的执行档、ELF 格式的执行档。在本文的这个部分，我会针对 Linux 系统是如何来辨别这些不同的可执行档，以及整体的执行流程来作一个说明。

　　我在此大略说明一下程序启动的流程,当我们在 shell 中输入指令时，会先去系统的路径中来寻找是否有该可执行档存在，如果找不到的话，就会显示出找不到该可执行档的讯息。如果找到的话，就会去呼叫 execve()来执行该档案，接下来 execve() 会呼叫 System Call sys_execv()，这是在Linux 中 User Mode 透过 80 号中断(int 80 ah=11)进入 Kernel Mode 所执行的第一个指令，之後在 Kernel 中陆续执行 do_exec()、 prepare_binprm()、read_exec()、search_binary_handler()，而在 search_binary_handler() 函式中，会逐一的去检查目前所执行档案的型态(看看是否为Script File、aout 或 ELF 档)，不过 Linux 所采用的方式是透过各个档案格式的处理程序来决定目前的执行档所属的处理程序。

　　如下图，会先去检验档案是否为 Script 档，若是直进入 Script 档的处理程序。若不是，则再进入 Aout 档案格式的处理程序，若该执行档为 Aout 的档案格式便交由 Aout档案格式的处理程序来执行。如果仍然不是的话，便再进入 ELF 档案格式的处理程序，如果都找不到的话，则传回错误讯息。

　　由这种执行的流程来看的话，如果 Linux Kernel 想要加入其他的执行档格式的话，就要在 search_binary_handler() 加入新的执行档的处理程序，这样一旦新的执行档格式产生後，在 Linux 下要执行时，因为在do_load_script、do_load_aout_binary、do_load_elf_binary都会传回错误，因此只有我们自己的 do_load_xxxx_binary 函式可以正确的接手整个执行档的处理流程，因此便可以达成新的档案格式置入的动作哩。

　　在函式 do_load_elf_binary () 执行时，首先会去检视目前的档案是否为 ELF 格式，如下程序码

if (elf_ex.e_ident[0] != 0x7f'  '
strncmp(&elf_ex.e_ident[1], "ELF", 3) != 0) 
goto out; 

　　便是去检查该档的前四个 bytes 是否为 0x7f 加上 “ELF” (0x 45 0x4c 0x46)，若非，则结束 do_load_elf_binary 的执行。之後，便是去检视我们之前提过的 e_type 属性，来得知是否为 ET_EXEC(Executable File) 或是ET_DYN(Shared Object File) 这两个值的其中之一

if (elf_ex.e_type != ET_EXEC && elf_ex.e_type != ET_DYN) 
goto out; 

　　如果都不是这两个值之一，便结束 do_load_elf_binary 的执行之後便是一连串读取 ELF 档表格的动作，在此就不多说，有兴趣的读者可以自行参阅/usr/src/linux/fs/binfmt_elf.c 的内容即可。

　　在此我们检视一个执行档由启动到结束的完整流程，首先这个执行档具有如下的程序码

#include  
int main() 
{ 
printf(" test "); 
} 

　　然後，透过如下的编程过程

gcc test.c ˉo test 

　　我们如果检视执行档的 ELF Header 可以得知它主要呼叫了 /lib/libc.so.6函式库中以下的函式

printf 
__deregister_frame_info 
__libc_start_main 
__register_frame_info 

　　接下来，我们便把程序的执行流程大略整理如下，而 execve("./test", ["./test"], []) 执行的流程，就是刚刚我们所提到的内容，若不熟悉的读者，可以再回头看看刚刚的内容，即可对 execve("./test", ["./test"], []) 的执行流程有大略的了解。在这里，我们会把整个执行流程更完整的来检视一遍。

　　首先，我们所在的执行环境会透过 execve("./test", ["./test"], []) 的函式呼叫来启动 test 执行档。

　　呼叫 open("/etc/ld.so.cache", O_RDONLY)，以唯读模式开启 ld.so.cache，这个档案的功能是作为动态函式库的快取，它会记录了目前系统中所存在的动态函式库的资讯以及这些函式库所存在的位置。所以说，如果我们在系统中安装了新的函式库时，我们便需要去更新这个档案的内容，以使新的函式库可以在我们的 Linux 环境中发生作用，我们可以透过 ldconfig 这个指令来更新 ld.so.cache 的内容。

　　呼叫 mmap(0, 9937, PROT_READ, MAP_PRIVATE, 3, 0)，把 ld.so.cache 档案映射到记忆体中，mmap 函式的宣告为 mmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)，在笔者的电脑上 ld.so.cache 的档案大小为 9937 bytes，PROT_READ代表这块记忆体位置是可读取的，MAP_PRIVATE 则表示产生一个行程私有的 copy-on-write 映射，因此这个呼叫会把整个 ld.so.cache 档案映射到记忆体中，在笔者电脑上所传回的映射记忆体起始位置为 0x40013000。

　　注: mmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)代表我们要求在档案 fd中，起始位置为offset去映射 length 长度的资料，到记忆体位置 start ，而 prot 是用来描述该记忆体位置的保护权限(例如:读、写、执行)，flags用来定义所映射物件的型态，例如这块记忆体是否允许多个 Process 同时映射到，也就是说一旦有一个 Process 更改了这个记忆体空间，那所有映射到这块记忆体的Process 都会受到影响，或是 flag 设定为 Process 私有的记忆体映射，这样就会透过 copy-on-write 的机制，当这块记忆体被别的 Process 修改後，会自动配置实体的记忆体位置，让其他的 Process 所映射到的记忆体内容与原本的相同。(有关mmap的其它应用，可参考本文最後的注一)