軟體學徒forever

原文作者： Eli Bendersky 原文連結： http://eli.thegreenplace.net/2012/08/13/how-statically-linked-programs-run-on-linux/   在這篇文章中，我想要探討當一個靜態連結的程式在 Linux 上執行時會發生什麼事情。靜態連結指的是一個程式執行時不需要額外的共享物件，即使是無所不在的 libc 也不需要。實際上，我們在 Linux 遇到的絕大多數程式並不是靜態連結的，需要一個或多個共享物件才能夠執行。然而，這類程式的執行流程牽涉較多細節，所以我想先說明靜態連結的程式。這可以為理解整體流程打下好的基礎，並允許我用較少的細節去討論主要的機制。我在未來會有另一篇文章來將動態連結的行程講述清楚。 Linux 核心 程式的執行起始於 Linux 核心 中。為了運行一個程式，一個行程會呼叫 exec 系列函式 其中之一。這系列的函式都非常相似，差別只在於傳入的程式的引數與環境變數。這些函數最後都會發出 sys_execve 系統呼叫 至 Linux 核心。 sys_execve 為了新程式的執行作了許多準備。要全部解釋完畢會超出這篇文章的目的 - 一本好的核心內部機制書籍對於理解這類細節會很有幫助[1]。我將會專住在對目前的討論有用的部份。 核心必須從硬碟讀取程式的可執行檔案至記憶體中並準備其執行。核心知道如何處理許多種類的二進位格式並且試著以相應的處理方式開啟檔案（這在 fs/exec.c 的  search_binary_handler 中發生）。不過，我們此處只先對 ELF 感興趣，這個格式的對應動作在函式 load_elf_binary 中（位於 fs/binfmt_elf.c）。 核心讀取程式的 ELF header，然後檢查 PT_INTERP segment 以確認是否有某個解譯器被指定。這邊就是靜態連結與動態連結開始有差異的地方。對於靜態連結的程式來說，沒有 PT_INTERP segment 。也是此篇文章要涵蓋的範圍。 核心接著根據 ELF program header 中的資訊將程式的 segments mapping 進記憶體中。最後，核心會直接修改 IP 暫存器的值為 ELF heade...

作者： Eli Bendersky 原文連結： http://eli.thegreenplace.net/2011/11/03/position-indepentent-code-pic-in-shared-libraries/ 我已經在 以前的一篇文章 中描述過，要將共享庫載入到行程的位址空間需要一些特殊的處理。簡單來說，當連結器建造出一個共享庫時，它沒有辦法事前就知道程式庫會被載入到那邊。這樣子一來，便產生了要如何引用此程式庫中資料與程式碼的問題，也就是說，到底要如何指向正確的記憶體的問題。 以Linux ELF共享庫來說，有兩個主要的方式來解決這個問題：     1. 載入時重定位     2. 位址無關程式碼 (PIC) 載入時重定位 已經解釋 過了。在這邊，我想要解釋第2種作法 - PIC。我原本想要在文中同時解釋x86與x64(也就是x86-64)，但當文章愈來愈長時，這樣變得很不實際。所以此文只會解釋PIC如何在x86上運作，特別挑選這個架構(而不是x64)是因為它並不是有考慮到PIC在設計的，以致於在其上實作PIC有一點巧妙。未來的文章(希望不會太久)將會處理x64上的PIC議題。 載入時重定位的一些問題 如同我們在之前文章所看到的，載入時重定位是相當直觀的一個方式，而且的確可以運作。另一方面，PIC是現今較為廣受歡迎的作法，通常也是建造共享庫時的建議作法。怎麼會這樣呢？因為載入時重定位存在著一些問題：它會需要額外的時間，並且使得程式庫的text section無法被共享。 首先，效能問題。如果一個共享庫有載入時重定位的項目時，就必須花點時間在應用程式載入時處理這些重定位。你或許會認為這個代價不會很高，畢竟載入器不必掃描整個text section，只需要察看重定位項目即可。但是如果一個複雜的軟體在起始時載入多個大型共享庫，並且每個共享庫必須先將它的重定位項目處理好，這個代價將會逐漸攀高，並造成應用程式明顯的啟動延遲。 再來，更嚴重的是text section無法共享的問題。共享庫一開始的首要目標是為了節省記憶體。多個應用程式都會使用一些共同的程式庫。如果共享庫的text section(就是代碼的部份)只需載入一次(然後以map的方式對映到多個行程的虛擬記憶體)，就能夠省...