既然程式最終都被變成了一條條機器碼去執行，那為什麼同一個程式，在同一臺電腦上，在Linux下可以運行，而在Windows下卻不行呢？

反過來，Windows上的程式在Linux上也是一樣不能執行的

可是我們的CPU並沒有換掉，它應該可以識別同樣的指令呀!!!

如果你和我有同樣的疑問，那這一節，我們就一起來解開。

1 編譯、鏈接和裝載：拆解程式執行

寫好的C語言代碼，可以通過編譯器編譯成彙編代碼，然後彙編代碼再通過彙編器變成CPU可以理解的機器碼，於是CPU就可以執行這些機器碼了

你現在對這個過程應該不陌生了，但是這個描述把過程大大簡化了

下麵，我們一起具體來看，C語言程式是如何變成一個可執行程式的。

過去幾節，我們通過gcc生成的文件和objdump獲取到的彙編指令都有些小小的問題

我們先把前面的add函數示例，拆分成兩個文件

• add_lib.c
  
• link_example.c

通過gcc來編譯這兩個文件，然後通過objdump命令看看它們的彙編代碼。

• objdump -d -M intel -S link_example.o
  

既然代碼已經被我們“編譯”成了指令

不妨嘗試運行一下 ./link_example.o

• 不幸的是，文件沒有執行許可權，我們遇到一個Permission denied錯誤

即使通過chmod命令賦予link_example.o文件可執行的許可權，運行 ./link_example.o 仍然只會得到一條cannot execute binary file: Exec format error的錯誤。

仔細看一下objdump出來的兩個文件的代碼，會發現兩個程式的地址都是從0開始

如果地址一樣，程式如果需要通過call指令調用函數的話，怎麼知道應該跳到哪一個文件呢？

無論是這裡的運行報錯，還是objdump出來的彙編代碼裡面的重覆地址

都是因為 add_lib.o 以及 link_example.o 並不是一個可執行文件（Executable Program），而是目標文件（Object File）

只有通過鏈接器（Linker） 把多個目標文件以及調用的各種函數庫鏈接起來，我們才能得到一個可執行文件

• gcc的-o參數，可以生成對應的可執行文件，對應執行之後，就可以得到這個簡單的加法調用函數的結果。
  

C語言代碼-彙編代碼-機器碼 過程，在我們的電腦上進行的時候是由兩部分組成:

• 第一個部分由編譯（Compile）、彙編（Assemble）以及鏈接（Link）三個階段組成
  三階段後，就生成了一個可執行文件link_example:

file format elf64-x86-64
Disassembly of section .init:
...
Disassembly of section .plt:
...
Disassembly of section .plt.got:
...
Disassembly of section .text:
...

 6b0:   55                      push   rbp
 6b1:   48 89 e5                mov    rbp,rsp
 6b4:   89 7d fc                mov    DWORD PTR [rbp-0x4],edi
 6b7:   89 75 f8                mov    DWORD PTR [rbp-0x8],esi
 6ba:   8b 55 fc                mov    edx,DWORD PTR [rbp-0x4]
 6bd:   8b 45 f8                mov    eax,DWORD PTR [rbp-0x8]
 6c0:   01 d0                   add    eax,edx
 6c2:   5d                      pop    rbp
 6c3:   c3                      ret    
00000000000006c4 <main>:
 6c4:   55                      push   rbp
 6c5:   48 89 e5                mov    rbp,rsp
 6c8:   48 83 ec 10             sub    rsp,0x10
 6cc:   c7 45 fc 0a 00 00 00    mov    DWORD PTR [rbp-0x4],0xa
 6d3:   c7 45 f8 05 00 00 00    mov    DWORD PTR [rbp-0x8],0x5
 6da:   8b 55 f8                mov    edx,DWORD PTR [rbp-0x8]
 6dd:   8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
 6e0:   89 d6                   mov    esi,edx
 6e2:   89 c7                   mov    edi,eax
 6e4:   b8 00 00 00 00          mov    eax,0x0
 6e9:   e8 c2 ff ff ff          call   6b0 <add>
 6ee:   89 45 f4                mov    DWORD PTR [rbp-0xc],eax
 6f1:   8b 45 f4                mov    eax,DWORD PTR [rbp-0xc]
 6f4:   89 c6                   mov    esi,eax
 6f6:   48 8d 3d 97 00 00 00    lea    rdi,[rip+0x97]        # 794 <\_IO\_stdin\_used+0x4>
 6fd:   b8 00 00 00 00          mov    eax,0x0
 702:   e8 59 fe ff ff          call   560 <printf@plt>
 707:   b8 00 00 00 00          mov    eax,0x0
 70c:   c9                      leave  
 70d:   c3                      ret    
 70e:   66 90                   xchg   ax,ax
...
Disassembly of section .fini:

...你會發現，可執行代碼dump出來內容，和之前的目標代碼長得差不多，但是長了很多

因為在Linux下，可執行文件和目標文件所使用的都是一種叫ELF（Execuatable and Linkable File Format）的文件格式，中文名字叫可執行與可鏈接文件格式

這裡面不僅存放了編譯成的彙編指令，還保留了很多別的數據。

• 第二部分，我們通過裝載器（Loader）把可執行文件裝載（Load）到記憶體中
  CPU從記憶體中讀取指令和數據，來開始真正執行程式
  2 ELF格式和鏈接：理解鏈接過程程式最終是通過裝載器變成指令和數據的，所以其實生成的可執行代碼也並不僅僅是一條條的指令
  我們還是通過objdump指令，把可執行文件的內容拿出來看看。

比如我們過去所有objdump出來的代碼里，你都可以看到對應的函數名稱，像add、main等等，乃至你自己定義的全局可以訪問的變數名稱，都存放在這個ELF格式文件里

這些名字和它們對應的地址，在ELF文件裡面，存儲在一個叫作符號表（Symbols Table）的位置里。符號表相當於一個地址簿，把名字和地址關聯了起來。

我們先只關註和我們的add以及main函數相關的部分

你會發現，這裡面，main函數里調用add的跳轉地址，不再是下一條指令的地址了，而是add函數的入口地址了，這就是EFL格式和鏈接器的功勞

ELF文件格式把各種信息，分成一個一個的Section保存起來。ELF有一個基本的文件頭（File Header），用來表示這個文件的基本屬性，比如是否是可執行文件，對應的CPU、操作系統等等。除了這些基本屬性之外，大部分程式還有這麼一些Section：

• 首先是.text Section，也叫作代碼段或者指令段（Code Section），用來保存程式的代碼和指令；
• 接著是.data Section，也叫作數據段（Data Section），用來保存程式裡面設置好的初始化數據信息；
• 然後就是.rel.text Secion，叫作重定位表（Relocation Table）。重定位表裡，保留的是當前的文件裡面，哪些跳轉地址其實是我們不知道的。比如上面的 link_example.o 裡面，我們在main函數裡面調用了 add 和 printf 這兩個函數，但是在鏈接發生之前，我們並不知道該跳轉到哪裡，這些信息就會存儲在重定位表裡；
• 最後是.symtab Section，叫作符號表（Symbol Table）。符號表保留了我們所說的當前文件裡面定義的函數名稱和對應地址的地址簿。

鏈接器會掃描所有輸入的目標文件，然後把所有符號表裡的信息收集起來，構成一個全局的符號表。然後再根據重定位表，把所有不確定要跳轉地址的代碼，根據符號表裡面存儲的地址，進行一次修正。最後，把所有的目標文件的對應段進行一次合併，變成了最終的可執行代碼。這也是為什麼，可執行文件裡面的函數調用的地址都是正確的

在鏈接器把程式變成可執行文件之後，要裝載器去執行程式就容易多了。裝載器不再需要考慮地址跳轉的問題，只需要解析 ELF 文件，把對應的指令和數據，載入到記憶體裡面供CPU執行就可以了。

3 總結

講到這裡，相信你已經猜到，為什麼同樣一個程式，在Linux下可以執行而在Windows下不能執行了。其中一個非常重要的原因就是，兩個操作系統下可執行文件的格式不一樣。

我們今天講的是Linux下的ELF文件格式，而Windows的可執行文件格式是一種叫作PE（Portable Executable Format）的文件格式。Linux下的裝載器只能解析ELF格式而不能解析PE格式。

如果我們有一個可以能夠解析PE格式的裝載器，我們就有可能在Linux下運行Windows程式了。這樣的程式真的存在嗎？

沒錯，Linux下著名的開源項目Wine，就是通過相容PE格式的裝載器，使得我們能直接在Linux下運行Windows程式的。

而現在微軟的Windows裡面也提供了WSL，也就是Windows Subsystem for Linux，可以解析和載入ELF格式的文件。

我們去寫可以用的程式，也不僅僅是把所有代碼放在一個文件里來編譯執行，而是可以拆分成不同的函數庫，最後通過一個靜態鏈接的機制，使得不同的文件之間既有分工，又能通過靜態鏈接來“合作”，變成一個可執行的程式。

對於ELF格式的文件，為了能夠實現這樣一個靜態鏈接的機制，裡面不只是簡單羅列了程式所需要執行的指令，還會包括鏈接所需要的重定位表和符號表。

4 推薦閱讀

更深入瞭解程式的鏈接過程和ELF格式，推薦閱讀《程式員的自我修養——鏈接、裝載和庫》的1～4章。這是一本難得的講解程式的鏈接、裝載和運行的好書。