既然程式最終都被變成了一條條機器碼去執行，那為什麼同一個程式，在同一臺計算機上，在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章。這是一本難得的講解程式的連結、裝載和執行的好書