ELF Executable and Linking Format

1. 概述

Executable and linking format(ELF)文件是x86 Linux系統下的一種經常使用目標文件(object file)格式，有三種主要類型:

(1)適於鏈接的可重定位文件(relocatable file)，可與其它目標文件一塊兒建立可執行文件和共享目標文件。

(2)適於執行的可執行文件(executable file)，用於提供程序的進程映像，加載的內存執行。

(3)共享目標文件(shared object file),鏈接器可將它與其它可重定位文件和共享目標文件鏈接成其它的目標文件，動態鏈接器又可將它與可執行文件和其它共享目標文件結合起來建立一個進程映像。

ELF文件格式比較複雜，本文只是簡要介紹它的結構，但願能給想了解ELF文件結構的讀者以幫助。具體詳盡的資料請參閱專門的ELF文檔。

2. 文件格式

爲了方便和高效，ELF文件內容有兩個平行的視角:一個是程序鏈接角度，另外一個是程序運行角度，如圖1所示。

ELF header在文件開始處描述了整個文件的組織，Section提供了目標文件的各項信息（如指令、數據、符號表、重定位信息等），Program header table指出怎樣建立進程映像，含有每一個program header的入口，Section header table包含每個section的入口，給出名字、大小等信息。

圖1

3. 數據表示

ELF數據編碼順序與機器相關，數據類型有六種，見表1。

4. ELF文件頭

象bmp、exe等文件同樣，ELF的文件頭包含整個文件的控制結構。它的定義以下：

 

#define EI_NIDENT 16 typedef struct{ unsigned char e_ident[EI_NIDENT]; Elf32_Half e_type; Elf32_Half e_machine; Elf32_Word e_version; Elf32_Addr e_entry; Elf32_Off e_phoff; Elf32_Off e_shoff; Elf32_Word e_flags; Elf32_Half e_ehsize; Elf32_Half e_phentsize; Elf32_Half e_phnum; Elf32_Half e_shentsize; Elf32_Half e_shnum; Elf32_Half e_shstrndx; }Elf32_Ehdr;

其中E_ident的16個字節標明是個ELF文件（7F+'E'+'L'+'F'+class +data+version+pad）。E_type表示文件類型，2表示可執行文件。E_machine說明機器類別，3表示386機器，8表示MIPS機器。E_entry給出進程開始的虛地址，即系統將控制轉移的位置。E_phoff指出program header table的文件偏移，e_phentsize表示一個program header表中的入口的長度（字節數表示），e_phnum給出program header表中的入口數目。相似的，e_shoff，e_shentsize，e_shnum 分別表示section header表的文件偏移，表中每一個入口的的字節數和入口數目。E_flags給出與處理器相關的標誌，e_ehsize給出ELF文件頭的長度（字節數表示）。E_shstrndx表示section名錶的位置，指出在section header表中的索引。

下面有個elf文件頭的例子，能夠對照理解，見圖2。

圖2

5. section header

目標文件的section header table能夠定位全部的section，它是一個Elf32_Shdr結構的數組，Section頭表的索引是這個數組的下標。有些索引號是保留的，目標文件不能使用這些特殊的索引。

Section包含目標文件除了ELF文件頭、程序頭表、section頭表的全部信息，並且目標文件section知足幾個條件:

(1)目標文件中的每一個section都只有一個section頭項描述，能夠存在不指示任何section的section頭項。

(2)每一個section在文件中佔據一塊連續的空間。

(3)Section之間不可重疊。

(4)目標文件能夠有非活動空間，各類headers和sections沒有覆蓋目標文件的每個字節，這些非活動空間是沒有定義的。

Section header結構定義以下：

 

typedef struct{ Elf32_Word sh_name; Elf32_Word sh_type; Elf32_Word sh_flags; Elf32_Addr sh_addr; Elf32_Off sh_offset; Elf32_Word sh_size; Elf32_Word sh_link; Elf32_Word sh_info; Elf32_Word sh_addralign; Elf32_Word sh_entsize; }Elf32_Shdr;

其中sh_name指出section的名字，它的值是後面將會講到的section header string table中的索引，指出一個以null結尾的字符串。Sh_type是類別，sh_flags指示該section在進程執行時的特性。Sh_addr指出若此section在進程的內存映像中出現，則給出開始的虛地址。Sh_offset給出此section在文件中的偏移。其它字段的意義不太經常使用，在此不細述。

文件的section含有程序和控制信息，系統使用一些特定的section，並有其固定的類型和屬性（由sh_type和sh_info指出）。下面介紹幾個經常使用到的section:「.bss」段含有佔據程序內存映像的未初始化數據，當程序開始運行時系統對這段數據初始爲零，但這個section並不佔文件空間。「.data.」和「data1」段包含佔據內存映像的初始化數據。「.rodata」和「.rodata1」段含程序映像中的只讀數據。「.shstrtab」段含有每一個section的名字，由section入口結構中的sh_name索引。「.strtab」段含有表示符號表(symbol table)名字的字符串。「.symtab」段含有文件的符號表，在後文專門介紹。「.text」段包含程序的可執行指令。

6. symbol table

目標文件的符號表包含定位或重定位程序符號定義和引用時所須要的信息。符號表入口結構定義以下:

 

typedef struct{ Elf32_Word st_name; Elf32_Addr st_value; Elf32_Word st_size; Unsigned char st_info; Unsigned char st_other; Elf32_Half st_shndx; }Elf32_Sym;

其中st_name包含指向符號表字符串表(strtab)中的索引，從而能夠得到符號名。St_value指出符號的值，多是一個絕對值、地址等。St_size指出符號相關的內存大小，好比一個數據結構包含的字節數等。St_info規定了符號的類型和綁定屬性，指出這個符號是一個數據名、函數名、section名仍是源文件名；而且指出該符號的綁定屬性是local、global仍是weak。

#####################################################################

動態連接，一個常常被人提起的話題。但在這方面不多有文章來闡明這個重要的軟件運行機制，只有一些關於動態連接庫編程的文章。本系列文章就是要從源代碼的層次來探討這個問題。

固然從文章的題目就能夠看出，intel平臺下的linux ELF文件的動態連接。一則是由於這一方面的資料查找比較方便，二則也是這個討論的意思比其它的動態連接要更爲重要（畢竟如今是intel的天下）。固然，有了這麼一個例子，其它的平臺下的ELF文件的動態連接也就大同小異。你能夠在閱讀完了本文以後"舉一隅，而反三隅"了。

因爲這是一個系列的文章，我計劃分三部分來寫，第一部分主要分析加載，涉及dl_open這個函數的內容，但因爲這個函數所包含的內容實在太多。這裏主要是它的_dl_map_object與_dl_init這兩個部分，由於這裏是把動態連接文件經過在ELF文件中的獲得信息映射到內存空間中，而_dl_init中是一個特殊的初始化。這是對面向對象的函數實現的。

第二部分我將分析函數解析與卸載，這裏要講的內容會比較多，但每個內容都不會多。首先是在前一篇中沒有說完的dl_open中的涉及的_dl_map_object_deps和_dl_relocate_object兩個函數內容，由於這些都與函數解析的內容直接相關，因此安排在這裏。而下面的函數解析過程_dl_runtime_resolve是在程序運行中的動態解析過程。這裏從本質上來說沒有太多的代碼，但它的精巧程度倒是最多的（正是我這三篇文章的核心之處）。最後是一個dl_close的實現。這裏是一個結尾的工做，順帶一下是_dl_signal_cerror，與_dl_catch_error的錯誤例外處理。

第三部將給出injectso實例分析與應用，會介紹一個應用了動態連接的實例，並能夠在往後的程序調試過程當中使用的injectso實例，它不只可讓咱們對前面所說的動態連接原理有一個更感性的認識，並且就這個實例而言，還能夠在之後的代碼開發過程當中來做爲一種動態打補丁的工具，甚至有可能，我會在之後的文章中會用這個工具來介紹新的技術。

1、歷史問題

關於動態連接，能夠說由來已久。若是追溯，最先的思想就在五十年代就有了，那時就想把一些公用的代碼放在內存中的一個地方上，在別的地址用call即是了。到後來又發展到了 loading overlays（就是把在程序運行生命期不一樣的代碼在不一樣的時間段被加入內存），這是在六十年代的事。但這隻能算是"濫觴"時期。接近於咱們如今所說的動態連接是在unix操做系統以後，由於從unix的設計結構而言，自己就是分紅模塊來實現一個複雜的功能的操做系統。但這些還不是現代意義上的動態連接，緣由是現代意義上的動態連接要符合兩個特色：

一、 動態的加載，就是當這個運行的模塊在須要的時候才被映射入運行模塊的虛擬內存空間中，如一個模塊在運行中要用到mylib.so中的myget函數，而在沒有調用mylib.so這個模塊中的其它函數以前，是不會把這個模塊加載到你的程序中（也就是內存映射），這些內容在內核中實現，用的是頁面異常機制（我可能在另外一篇文章中提到這個問題）。

二、 動態的解析，就是當要調用的函數被調用的時候，纔會去把這個函數在虛擬內存空間的起始地址解析出來，再寫到專門在調用模塊中的儲存地址內，如前面所說的你已經調用了myget，因此mylib.so模塊確定已經被映射到了程序虛擬內存之中，而若是你再調用mylib.so中的myput函數，那它的函數地址就在調用的時候纔會被解析出來。

（注：這裏用的程序就是通常所說的進程process，而模塊既多是你的程序的二進制代碼，也多是被你的程序所依賴的別的共享連接文件-------一樣ELF格式。）

在這兩點中頗有點像如今的操做系統中對內存的操做，也就是隻有當要用到一個內存空間中的時候纔會進行虛擬空間映射，而不是過早的把全部的空間映射好，而只有當要從這個內存空間讀的時候才分配物理空間。這有點像第一條。而只有當對這個內存空間進行寫的時候產生一個COW（copy on write）。這就有點像第二條。

這樣的好處就是充分避免沒必要要的開銷。由於任何一個程序在運行的時候，大部分狀況下，不可能用到全部的調用函數。

這樣的思想方法提出與實現都是在八十年代的sun公司的SunOS的系統上。

關於這一段歷史，請你參見資料[1]。

ELF二進制格式文件與現代的動態連接思想大體是在同一時段造成的，它的來源是AT&T公司的最先的unix中的a.out二進行文件格式。Bell labs的工做人員爲了使這種在unix的早期主要的文件格式適應當時新的軟件與操做系統的要求（如aix,SunOS,HP-UX這樣的unix變種，對更普遍的應用程序的擴展要求，對面向對象的支持等等），就發明了ELF文件格式。

我在這裏並不詳細討論ELF文件的具體細節，這原本就能夠寫一篇很長的文章，你能夠參看資料[2]來獲得關於它的ABI（application binary interface的規範）。但在ELF文件所採用的那種分層的管理方式卻不只在動態連接中起着重要的做用，並且這一思想能夠說是咱們計算機中的最古老，也是最經典的思想。

對每一個ELF文件，都有一個ELF header，在這裏的每一個header有兩個數據成員，就是

Elf32_Off e_phoff; Elf32_Off e_shoff;

它們分別表明了program header 與section header 在ELF文件中的偏移量。Program header 是總綱，而section header 則是第一個小目。

Elf32_Addr sh_addr; Elf32_Off sh_offset;

Sh_addr這個section 在內存中的映射地址（對動態連接庫而言，這是一個相對量，它與整個ELF文件被加載的l_addr造成絕對地址）。Sh_offset是這個section header在文件中的偏移量。

用一圖來表示就是這樣的，它就是用elf header 來管理了整個ELF文件：

 

舉個例子，若是要從一個ELF動態連接庫文件中，根據已知的函數名稱，找到相應的函數起始地址，那麼過程是這樣的。

先從前面的ELF 的ehdr中找到文件的偏移e_phoff處，在這其中找到爲PT_DYNAMIC 的d_tag的phdr，從這個地址開始處找到DT_DYNAMIC的節，最後從其中找到這樣一個Elf32_Sym結構，它的st_name所指的字符串與給定的名稱相符，就用st_value即是了。

這種的管理模式，能夠說很複雜，有時會看起來是繁瑣。如找一個function 的起始地址就要從 elf header >>program header >>symbol section >>function address 這樣的四個步驟。但這裏的根本的緣由是咱們的計算機是線性尋址的，而且馮*諾依曼提出的計算機體系結構相關，因此在前面說這是一個古老的思想。但一樣也是因爲這樣的一個ELF文件結構，頗有利於ELF文件的擴充。咱們能夠設想，若是有一天，咱們的ELF文件爲了某種緣由，對它進行加密。這時若是要在ELF文件中保存密鑰，這時候能夠在ELF文件中開闢一個專門的section encrypt ，這個section 的type 就是ST_ENCRYPT，那不就是能夠了嗎？這一點就能夠看出ELF文件格式設計者當初的苦心了（如今這個真的有這麼一個節了）。

回頁首

2、代碼舉例

講了這麼多，尚未真正講到在intel 32平臺下linux動態連接庫的加載與調用。在通常的狀況下，咱們所編寫的程序是由編譯器與ld.so這個動態連接庫來完成的。而若是要顯式的調用某一個動態連接庫中的程序，則下面是一個例子。

#include <dlfcn.h> #include <stdio.h> main() { void *libc; void (*printf_call)(); char* error_text; if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY)) { printf_call=dlsym(libc,"printf"); (*printf_call)("hello, world\n"); dlclose(libc); return 0; } error_text= dlerror(); printf(error_test); return -2; }

在這裏先用dlopen來打開一個動態連接庫文件，而這個過程比咱們這裏看到的內容多的多，我會在下面用很大的篇幅來講明這一點，而它返回的參數是一個指針，確切的說是struct link_map*，而dlsym就是在這個struct link_map* 與函數名稱一塊兒決定這個函數在這個進程中的地址，這個過程用術語來講就是函數解析(function resolution)。而最後的dlclose就是釋放剛纔在dlopen中獲得的資源，這個過程與咱們在加載的share object file module，內核中的程序是大概相同的，只不過這裏是在用戶態，而那個是在內核態。從函數的複雜性而言這裏還要複雜一些（最後有一點要說明，若是你想編譯上面的文件-------文件名若是是test那就不能用通常的gcc -o test test.c ，而應該是gcc -c test test.c -ldl這樣才能編譯經過，由於不這樣編譯器會找不到dlopen 與dlsym dlclose這些特別函數的庫文件libdl.so.2， -ldl 就是加載它的標誌的）。

回頁首

3、_dl_open加載過程分析

本文以及之後的兩篇文章將都以上面的程序所展現的而講解。也就是以dlopen >> dlsym >> dlclose 的方式 來說解這個過程，但有幾點先要說明： 我在這裏所展現的源代碼來自glibc 2.3.2版本。但因爲原來的代碼，從代碼的移植與健壯的考慮，而有許多的防止出錯，與關於不一樣平臺的代碼，在這裏大部分是出錯處理代碼，我把這些的代碼都刪除。而且只以intel 32平臺下的代碼爲準。還有，在這裏的還考慮到了多線程狀況下的動態連接庫加載，這裏也不予以包括在內（由於如今的linux內核中沒有對內核線程的支持）。因此你所看到的代碼，在儘可能保證說明動態連接加載與函數解析的狀況做了多數的刪減，代碼量大概只有原來的四分之一左右，同時最大程度保持了原來代碼的風格，突出核心功能。儘管如此，仍是有高達2000行以上的代碼，請你們耐心的解讀。我也會對其中可能的難解之處做出詳細的說明。讓你們真正體會到代碼設計與動態解析的真諦。

第一個函數在dl-open.c中

2672 void* internal_function 2673 _dl_open (const char *file, int mode, const void *caller) 2674 { 2675 struct dl_open_args args; 2676 2677 __rtld_lock_lock_recursive (GL(dl_load_lock)); 2678 2679 args.file = file; 2680 args.mode = mode; 2681 args.caller = caller; 2682 args.map = NULL; 2683 2684 dl_open_worker(&args); 2685 __rtld_lock_unlock_recursive (GL(dl_load_lock)); 2686 2687 }

這裏的internal_function是代表這個函數從寄存器中傳遞參數，而它的定義在configure.in中獲得的。

# define internal_function __attribute__ ((regparm (3), stdcall))

這其中的regparm就是gcc的編譯選項是從寄存器傳遞3個參數，而stdcall代表這個函數是由調用函數來清棧，而通常的函數是由調用者來負責清棧，用的是cdecl。 __rtld_lock_lock_recursive (GL(dl_load_lock));與__rtld_lock_unlock_recursive (GL(dl_load_lock));在如今尚未徹底定義，至少在linux中是沒有的，但能夠參考在linux/kmod.c 中的request_module中爲了防止過分嵌套而加的一個鎖。

而其它的內容就是一個封裝了。

dl_open_worker是真正作動態連接庫映射並構造一個struct link_map而這是一個絕對重要的數據結構它的定義因爲太長，我會放在第二篇文章結束的附錄中介紹，由於那時你能夠回頭再理解動態連接庫加載與解析的過程，而在下面的具體函數中出現了做實用性的解釋，下面咱們分段來看：

_dl_open() >> dl_open_worker() 2532 static void 2533 dl_open_worker (void *a) 2534 { …………………….. 2547 args->map = new = _dl_map_object (NULL, file, 0, lt_loaded, 0, mode);

這裏就是調用_dl_map_object 來把文件映射到內存中。原來的函數要從不一樣的路徑搜索動態連接庫文件，還要與SONAME（這是動態連接庫文件在運行時的別名）比較，這些內容我在這裏都刪除了。

_dl_open() >> dl_open_worker() >> _dl_map_object() 1693 struct link_map * 1694 internal_function 1695 _dl_map_object (struct link_map *loader, const char *name, int preloaded, 1696 int type, int trace_mode, int mode) 1697 { 1698 int fd; 1699 char *realname; 1700 char *name_copy; 1701 struct link_map *l; 1702 struct filebuf fb; 1703 1704 1705 /* Look for this name among those already loaded. */ 1706 for (l = GL(dl_loaded); l; l = l->l_next) 1707 { 1708 if (!_dl_name_match_p (name, l)) ……………. 1721 return l; 1722 } 1723 1724 fd = open_path (name, namelen, preloaded, &env_path_list, 1725 &realname, &fb); 1726 1727 l = _dl_new_object (name_copy, name, type, loader); 1728 1729 return _dl_map_object_from_fd (name, fd, &fb, realname, loader, type, mode); 1730 1731 1732 }/*end of _dl_map_object*/

這裏先在已經被加載的一個動態連接庫的鏈中搜索，在1706與1721行中就是做這一件事。想起來也很簡單，由於可能在一個可執行文件依賴好幾個動態連接庫。而其中有幾個動態連接庫或許都依賴於同一個動態連接文件，可能早就加載了這樣一個動態連接庫，就是這樣的狀況了。

下面open_path是一個關鍵，這裏要指出的是env_path_list獲得的方式有幾種，一是在系統環境變量，二就是DT_RUNPATH所指的節中的字符串（參見下面的 附錄），還有更復雜的，是從其它要加載這個動態連接庫文件的動態連接庫中獲得的環境變量-------這些問題咱們都不說明了。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> open_path() 1289 static int open_path (const char *name, size_t namelen, int preloaded, 1290 struct r_search_path_struct *sps, char **realname, 1291 struct filebuf *fbp) 1292 1293 { 1294 struct r_search_path_elem **dirs = sps->dirs; 1295 char *buf; 1296 int fd = -1; 1297 const char *current_what = NULL; 1298 int any = 0; 1299 1300 buf = alloca (max_dirnamelen + max_capstrlen + namelen); 1301 1302 do 1303 { 1304 struct r_search_path_elem *this_dir = *dirs; 1305 size_t buflen = 0; ……………… 1310 struct stat64 st; 1311 1312 1313 edp = (char *) __mempcpy (buf, this_dir->dirname, this_dir->dirnamelen); 1314 for (cnt = 0; fd == -1 && cnt < ncapstr; ++cnt) 1315 { 1316 /* Skip this directory if we know it does not exist. */ 1317 if (this_dir->status[cnt] == nonexisting) 1318 continue; 1319 1320 buflen = ((char *) __mempcpy (__mempcpy (edp, capstr[cnt].str, 1321 capstr[cnt].len), name, namelen)- buf); 1322 1323 1324 fd = open_verify (buf, fbp); 1325 1326 1327 __xstat64 (_STAT_VER, buf, &st); 1328 1329 1341 } 1342 ……………. 1358 }

在這上面的alloc是在棧上分配空間的函數，這樣就不用擔憂在函數結束的時候出現內存泄漏的狀況（好的程序員真的要對內存的分配熟諳於心）。1313行就是把r_search_path_elem的dirname copy過來，而在1320至1321行的內容就是爲這個路徑加上最後的'/'路徑分隔號，而capstr就是根據不一樣的操做系統與體系獲得的路徑分隔號。這實際上是一個很好的例子，由於__memcpy返回的參數是dest string所copy的最後的一個字節的地址，因此每copy以後就會獲得新的地址，若是用strncpy來寫的話，就要用這樣的方法

strncpy(edp, capstr[cnt].str, capstr[cnt].len); edp+=capstr[cnt].len; strncpy(edp,name, namelen); edp+=namelen; buflen=edp-buf;

這就要用四句，而這裏用了一句就能夠了。

下面的open_verify是打開這個buf所指的文件名，fbp是從這個文件獲得的文件開時1024字節的內容,並對文件的有效性進行檢查，這裏最主要的是ELF_IMAGIC覈對。若是成功，就返回一個大於-1的文件描述符。整個open_path就這樣完成了打開文件的方法。

_dl_new_object是一個分配struct link_map* 數據結構並填充一些最基本的參數。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_new_object() 2027 struct link_map * 2028 internal_function 2029 _dl_new_object (char *realname, const char *libname, int type, 2030 struct link_map *loader) 2031 2032 { 2033 struct link_map *l; 2034 int idx; 2035 size_t libname_len = strlen (libname) + 1; 2036 struct link_map *new; 2037 struct libname_list *newname; 2038 2039 new = (struct link_map *) calloc (sizeof (*new) + sizeof (*newname) 2040 + libname_len, 1); 2041 ……………….. 2046 2047 new->l_name = realname; 2048 new->l_type = type; 2049 new->l_loader = loader; 2050 2051 new->l_scope = new->l_scope_mem; 2052 new->l_scope_max = sizeof (new->l_scope_mem) / sizeof (new->l_scope_mem[0]); 2053 2054 if (GL(dl_loaded) != NULL) 2055 { 2056 l = GL(dl_loaded); 2057 while (l->l_next != NULL) 2058 l = l->l_next; 2059 new->l_prev = l; 2060 /* new->l_next = NULL; Would be necessary but we use calloc. */ 2061 l->l_next = new; 2062 2063 /* Add the global scope. */ 2064 new->l_scope[idx++] = &GL(dl_loaded)->l_searchlist; 2065 } 2066 else 2067 GL(dl_loaded) = new; 2068 ++GL(dl_nloaded); …………. 2080 2081 return new; 2082 2083 }

在2039行的內存分配是一個把libname 與name的數據結構也一同分配，是一種零用整取的策略。從2043-2053行都是爲struct link_map 的成員數據賦值。從2054-2067行則是把新的struct link_map* 加入到一個單鏈中，這是在之後是頗有用的，由於這樣在一個執行文件中若是要總體管理它相關的動態連接庫，就能夠以單鏈遍歷。

若是要加載的動態連接庫尚未被映射到進程的虛擬內存空間的話，那只是準備工做，真正的要點在_dl_map_object_from_fd()這個函數開始的。由於這以後，每一步都有關動態連接庫在進程中發揮它的做用而必須的條件。

這上段比較長，因此分段來看，

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() 1391 struct link_map * 1392 _dl_map_object_from_fd (const char *name, int fd, struct filebuf *fbp, 1393 char *realname, struct link_map *loader, int l_type, 1394 int mode) 1395 1396 { 1397 1398 struct link_map *l = NULL; 1399 const ElfW(Ehdr) *header; 1400 const ElfW(Phdr) *phdr; 1401 const ElfW(Phdr) *ph; 1402 size_t maplength; 1403 int type; 1404 struct stat64 st; 1405 1406 __fxstat64 (_STAT_VER, fd, &st); ………… 1413 for (l = GL(dl_loaded); l; l = l->l_next) 1414 if (l->l_ino == st.st_ino && l->l_dev == st.st_dev) 1415 { ………. 1418 __close (fd); …………… 1422 free (realname); 1423 add_name_to_object (l, name); 1424 1425 return l; 1426 }

這裏先開始就要從再找一遍，若是找到了已經有的struct link_map* 要加載的libname（的而比較的依據是它的與st_ino，這是物理文件在內存中編號，且文件的設備號st_dev相同，這是從比較底層來比較文件，具體的緣由，你能夠參看我將要發表的《從linux的內存管理看文件共享的實現》）。之因此採起這樣再查一遍，由於若是進程從要開始打開動態連接庫文件，走到這裏可能要通過很長的時間（據我做的實驗來看，對第一次打開的文件大概也就在200毫秒左右---------主要的時間是硬盤的尋道與讀盤，但這對於計算機的進程而言已是很長的時間了。）因此，有可能別的線程已經讀入了這個動態連接庫，這樣就沒有必要再作下去了。這與內核在文件的打開文件所用的思想是一致的。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() 1427 1428 /* This is the ELF header. We read it in `open_verify'. */ 1429 header = (void *) fbp->buf; 1430 1431 l->l_entry = header->e_entry; 1432 type = header->e_type; 1433 l->l_phnum = header->e_phnum; 1434 1435 maplength = header->e_phnum * sizeof (ElfW(Phdr)); 1436

這一段所做的爲下面的ELF文件的分節映射入內存作一點準備（要讀寫phdr的數組）。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() 1438 /* Scan the program header table, collecting its load commands. */ 1439 struct loadcmd 1440 { 1441 ElfW(Addr) mapstart, mapend, dataend, allocend; 1442 off_t mapoff; 1443 int prot; 1444 } loadcmds[l->l_phnum], *c; 1445 size_t nloadcmds = 0;

這裏把數據結構定義在函數內部，能保證這是一個局部變量定義，與面向對象中的private的效果是同樣的。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() 1448 for (ph = phdr; ph < &phdr[l->l_phnum]; ++ph) 1449 switch (ph->p_type) 1450 { ……….. 1454 case PT_DYNAMIC: 1455 l->l_ld = (void *) ph->p_vaddr; 1456 l->l_ldnum = ph->p_memsz / sizeof (ElfW(Dyn)); 1457 break; 1458 1459 case PT_PHDR: 1460 l->l_phdr = (void *) ph->p_vaddr; 1461 break; 1462 1463 case PT_LOAD: ………….. 1467 c = &loadcmds[nloadcmds++]; 1468 c->mapstart = ph->p_vaddr & ~(ph->p_align - 1); 1469 c->mapend = ((ph->p_vaddr + ph->p_filesz + GL(dl_pagesize) - 1) 1470 & ~(GL(dl_pagesize) - 1)); 1471 c->dataend = ph->p_vaddr + ph->p_filesz; 1472 c->allocend = ph->p_vaddr + ph->p_memsz; 1473 c->mapoff = ph->p_offset & ~(ph->p_align - 1); ………….. 1480 c->prot = 0; 1481 if (ph->p_flags & PF_R) 1482 c->prot |= PROT_READ; 1483 if (ph->p_flags & PF_W) 1484 c->prot |= PROT_WRITE; 1485 if (ph->p_flags & PF_X) 1486 c->prot |= PROT_EXEC; 1488 break; ………… 1493 }

在ELF文件的規範中，根據不一樣的program header 不一樣，要實現不一樣的功能，採用不一樣的處理策略，具體的內容請參看 附錄2中的說明。這裏沒有出現通常的default 但實際運行與下面的語句是等價的：

default: continue;

真是達到程序簡潔的特色。

但有一個特別要指出的是PT_LOAD的那些，把全部的能夠加載的節都在加載的數據結構中loadcmds中構建完成，是一個好的想法。特別是指針的妙用，值得學習(1467 c = &loadcmds[nloadcmds++];)。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() 1498 c = loadcmds; ………… 1501 maplength = loadcmds[nloadcmds - 1].allocend - c->mapstart; 1502 1503 if (__builtin_expect (type, ET_DYN) == ET_DYN) 1504 { ……………. 1521 l->l_map_start = (ElfW(Addr)) __mmap ((void *)0, maplength, 1522 c->prot, MAP_COPY | MAP_FILE, 1523 fd, c->mapoff); 1524 1525 l->l_map_end = l->l_map_start + maplength; 1526 l->l_addr = l->l_map_start - c->mapstart; ……….. 1535 __mprotect ((caddr_t) (l->l_addr + c->mapend), 1536 loadcmds[nloadcmds - 1].allocend - c->mapend, 1537 PROT_NONE); 1538 1539 goto postmap; 1540 }

在1521-1526行之間就是把整個文件都進行了映射，妙處在1498行與1501行，是把頭與尾的兩個PT_LOAD program header 的內容都計算在內了。而1503行就是咱們這裏的情景，由於這是動態連接庫的加載。而1535行的修改虛擬內存的屬性，就是把映射在最高地址的空白失效。這是一種保護。爲了防止有人利用這裏大作文章。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() 1546 while (c < &loadcmds[nloadcmds]) 1547 { 1548 1549 postmap: 1550 if (l->l_phdr == 0 1551 && (ElfW(Off)) c->mapoff <= header->e_phoff 1552 && ((size_t) (c->mapend - c->mapstart + c->mapoff) 1553 >= header->e_phoff + header->e_phnum * sizeof (ElfW(Phdr)))) …… 1555 l->l_phdr = (void *) (c->mapstart + header->e_phoff - c->mapoff); 1556 1557 if (c->allocend > c->dataend) 1558 { ……….. 1561 ElfW(Addr) zero, zeroend, zeropage; 1562 1563 zero = l->l_addr + c->dataend; 1564 zeroend = l->l_addr + c->allocend; 1565 zeropage = ((zero + GL(dl_pagesize) - 1) 1566 & ~(GL(dl_pagesize) - 1)); 1567 1568 if (zeroend < zeropage) ………. 1571 zeropage = zeroend; 1572 1573 if (zeropage > zero) 1574 { ……. 1576 if ((c->prot & PROT_WRITE) == 0) 1577 { 1578 /* Dag nab it. */ 1579 __mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) 1580 - 1)), GL(dl_pagesize), 1581 c->prot|PROT_WRITE) < 0); 1582 1583 } 1584 memset ((void *) zero, '\0', zeropage - zero); 1585 if ((c->prot & PROT_WRITE) == 0) 1586 __mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), 1587 GL(dl_pagesize), c->prot); 1588 } 1589 1590 if (zeroend > zeropage) 1591 { …….. 1593 caddr_t mapat; 1594 mapat = __mmap ((caddr_t) zeropage, zeroend - zeropage, 1595 c->prot, MAP_ANON|MAP_PRIVATE|MAP_FIXED, 1596 ANONFD, 0); 1597 1598 } 1599 } 1600 1601 ++c; 1602 }

這裏所做的與上面的相相似，根據在前面從PT_LOAD program header 獲得的文件映射的操做屬性進行修改，但在zeroend>zerorpage的時候不一樣，把它映射成爲進程獨享的數據空間。這也就是通常的初始化數據區BSS的地方。由於zeroend是在文件中的映射的頁面對齊尾地址，而zeropage是文件中的內容映射的頁面對齊尾地址，這其中的差就是爲未初始化數據準備的，這在1593-1597行之間體現，要把它的屬性改爲可寫的，且全爲0。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() 1606 if (l->l_phdr == NULL) 1607 { …….. 1611 ElfW(Phdr) *newp = (ElfW(Phdr) *) malloc (header->e_phnum 1612 * sizeof (ElfW(Phdr))); 1613 1614 l->l_phdr = memcpy (newp, phdr, 1615 (header->e_phnum * sizeof (ElfW(Phdr)))); 1616 l->l_phdr_allocated = 1; 1617 } 1618 else 1619 /* Adjust the PT_PHDR value by the runtime load address. */ 1620 (ElfW(Addr)) l->l_phdr += l->l_addr;

把phdr 就是program header 也歸入struct link_map的管理之中，通常的狀況是不會有的，因此要copy過來。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() 1625 elf_get_dynamic_info (l);

這裏調用的函數elf_get_dynamic_info是在加載過程當中最重要的一個之一，由於在這以後的幾乎全部的對動態連接管理的內容都要用要與這裏的l_info數據組相關。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() >> elf_get_dynamic_info() 2826 static inline void __attribute__ ((unused, always_inline)) 2827 elf_get_dynamic_info (struct link_map *l) 2828 { 2829 ElfW(Dyn) *dyn = l->l_ld; 2830 ElfW(Dyn) **info; 2831 2832 2833 info = l->l_info; 2834 2835 while (dyn->d_tag != DT_NULL) 2836 { 2837 if (dyn->d_tag < DT_NUM) 2838 info[dyn->d_tag] = dyn; …………… 2853 ++dyn; 2854 } …………. 2858 if (l->l_addr != 0) 2859 { 2860 ElfW(Addr) l_addr = l->l_addr; 2861 2862 if (info[DT_HASH] != NULL) 2863 info[DT_HASH]->d_un.d_ptr += l_addr; 2864 if (info[DT_PLTGOT] != NULL) 2865 info[DT_PLTGOT]->d_un.d_ptr += l_addr; 2866 if (info[DT_STRTAB] != NULL) 2867 info[DT_STRTAB]->d_un.d_ptr += l_addr; 2868 if (info[DT_SYMTAB] != NULL) 2869 info[DT_SYMTAB]->d_un.d_ptr += l_addr; ………………. 2874 ………… 2876 if (info[DT_REL] != NULL) 2877 info[DT_REL]->d_un.d_ptr += l_addr; …………. 2879 2880 if (info[DT_JMPREL] != NULL) 2881 info[DT_JMPREL]->d_un.d_ptr += l_addr; 2882 if (info[VERSYMIDX (DT_VERSYM)] != NULL) 2883 info[VERSYMIDX (DT_VERSYM)]->d_un.d_ptr += l_addr; 2884 } …………. 2889 }

上面的__attribute__ 中的unused 是爲了消除編譯器在-Wall 狀況下對於其中可能沒有用到在函數中的局部變量發出警告，而alwayse_inline，很好解釋，就是內聯函數的強制標誌。

2829行的l->l_ld是在前面的__dl_map_object_from_fd中的1455被給定的。也就是全部關於動態連接節的所在地址（參看 附錄B中的解釋）。

很明顯在2835至2854行之間的循環就是把l_info的內容都填充好。 這爲以後有很大的做用，由於這些節是能夠找到如函數名與定位信息的，這裏的的妙處是把數組的偏移量與d_tag相關聯，代碼簡潔。

2856至2885即是對動態連接庫的調整過程（這裏調整的每個節都是與函數解析有重要關係的，詳細內容可參看 附錄A），若是咱們考慮的更遠一點，在前面的函數中的1521行一開始把整個文件連續的映射入內存，在這裏就很好的獲得解釋，若是不是連續的，就沒有辦法在這裏做一個統一的調整了。

_dl_open() >> dl_open_worker() >> _dl_map_object() >> _dl_map_from_fd() 1662 /* Finally the file information. */ 1663 l->l_dev = st.st_dev; 1664 l->l_ino = st.st_ino; 1667 return l; 1670 }

最後就是把設備號與節點號加入就完成了最後的dl_map_object就好了，回頭看1414行中對已經加載的文件的搜索，就能夠明白這裏的做用了。

再回到dl_open_worker中

_dl_open() >> dl_open_worker() 2550 /* It was already open. */ 2551 if (new->l_searchlist.r_list != NULL) 2552 { ……. 2556 if ((mode & RTLD_GLOBAL) && new->l_global == 0) 2557 (void) add_to_global (new); 2558 2559 /* Increment just the reference counter of the object. */ 2560 ++new->l_opencount; 2561 2562 return; 2563 }

這就是對已經被打開了的，就對l_opencount加一返回了。但爲何要在2551行以後做出這一判斷呢，那是在下面的代碼有關，_dl_map_object_deps會把l_searchlist加載入。

_dl_open() >> dl_open_worker() 2565 /* Load that object's dependencies. */ 2566 _dl_map_object_deps (new, NULL, 0, 0, mode & __RTLD_DLOPEN); …………… 2573 l = new; 2574 while (l->l_next) 2575 l = l->l_next; 2576 while (1) 2577 { 2578 if (! l->l_relocated) 2579 { 2580 _dl_relocate_object (l, l->l_scope, lazy, 0); 2581 } 2582 2583 if (l == new) 2584 break; 2585 l = l->l_prev; 2586 }

在這裏的_dl_map_object_deps會填充l_searchlist.r_list，對於這個函數與下面的_dl_relocate_object因爲與函數的解析關係比較大，因此我放在《Intel平臺下linux中ELF文件動態連接的加載、解析及實例分析（中）-----------函數解析與卸載篇》講解。但能夠把這個看成這個新加載的動態連接庫的所依賴的動態連接庫的struct link_map* 放入這個指針的列表中(就是l_search_list中)，_dl_relocate_object是對這個動態連接庫中的函數重定位，而這裏用的，這裏之因此用的是while (1) 2576行，是由於在前面用的_dl_map_object_deps會把這個動態連接庫所依賴的動態連接庫也加載進來，這其中就會有沒有重定位的。

_dl_open() >> dl_open_worker() 2592 for (i = 0; i < new->l_searchlist.r_nlist; ++i) 2593 if (++new->l_searchlist.r_list[i]->l_opencount > 1 2594 && new->l_searchlist.r_list[i]->l_type == lt_loaded) 2595 { 2596 struct link_map *imap = new->l_searchlist.r_list[i]; 2597 struct r_scope_elem **runp = imap->l_scope; 2598 size_t cnt = 0; 2599 2600 while (*runp != NULL) 2601 { ………… 2605 if (*runp == &new->l_searchlist) 2606 break; 2607 2608 ++cnt; 2609 ++runp; 2610 } 2611 2612 if (*runp != NULL) 2613 /* Avoid duplicates. */ 2614 continue; ………… 2642 imap->l_scope[cnt++] = &new->l_searchlist; 2643 imap->l_scope[cnt] = NULL; 2644 }