軟體學徒forever

一個多月沒有寫 blog 了...並不是沒有東西想寫，而是剛好換了新工作，並且接了幾個有時程壓力的任務，所以每天都累得跟狗一樣... :P Anyway，趁今天早點下班，將一個工作上遇到的連結問題紀錄一下，或許對某些朋友剛好有幫助。問題是這樣的，在某個使用 MIPS GNU toolchain 的環境中，原本一份可以順利編譯的 code ，今天加了一點  code 後，突然出現了連結錯誤： relocation truncated to fit: R_MIPS_GPREL16 against `no symbol' 大家似乎都第一次遇到這個錯誤，google 一陣子找不太到直接解法，但是隱約看到有人提到跟 small data section、register GP 有關，記得在 See MIPS Run 中有描述過類似的句子，翻開教科書(chapter 2)，果然提到 GP 可能會被利用來作為快速的 addressing 方式，但由於要在一個指令作完 addressing ，所以只能用到一個 32 bits 指令的 16 bits，所以如果是以 GP-relative relative addressing 方式來作 relocation ，就必須注意資料必須在 GP 的前後 32KB 的範圍。也就是說，我們有兩種解法： 檢查 toolchain 將哪些 sections 的存取或指令用了 GP-relative addressing，然後改寫 linker script 將這些 sections 與 script 中的 _gp 排近一點(在 reset.S 之類的地方通常會拿 _gp 當作 GP 的值)。 利用編譯選項 -G0，使其不要產生 small data section，而這看起來似乎就是靜態連結時的唯一一種會用的 GP-relative addressing 的 section 。  我們採用方法1，因為方法2似乎有人有遇過不少問題，為了避免又撞到這類 link error 問題，先用安全點的作法。:-)

原文作者： 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/11/position-independent-code-pic-in-shared-libraries-on-x64/ 前一篇文章 解釋過與位址無關程式碼（position independent code, PIC）如何運作，並使用在 x86 上編譯過的程式作為範例。我承諾過在另一篇文章中涵蓋 x64 上的 PIC ，也就是現在這篇。既然大家都已經了解 PIC 的基本原理，這篇文章將不會牽扯太多細節。一般情況下，概念在不同平台下都是相似的，但細節會因為機器架構而有所不同。 RIP-relative 定址 在 x86 上，函式的呼叫（使用 call 指令）使用與目前指令相對位移的方式定址，資料的取用（使用 mov 指令）只支援絕對定址。既然 PIC 無可避免地需要利用 IP-relative 的定址方式，絕對位址就不容易與 PIC 同時存在，而 這也造成我們在前一篇文章看到 PIC 會比較沒有效率的原因。 x64 透過一個新的"RIP-relative 定址模式"修正了這點，這是 64 位元的 mov 指令去存去記憶體的預設模式（此模式也在其他指令中使用，像 lea ）。根據"英特爾架構手冊第二冊"中的說明：   一個新的定址模式，RIP-relative（相對於 instruction-pointer），在64 位元模式中被實作。一種有效率的方式去增加相對於指向下一個指令的 64 位元 RIP 的位移   在 RIP-relative 模式中的位移長度為 32 位元。由於正負值的位移都有需要，所以在 RIP 中的此種模式，支援的最大位移大概有最多 +/- 2GB 的位移。 在 x64 PIC 中取用資料 – 一個例子 作為一個簡單的對照，我會使用跟前篇文章同樣的 C 代碼作為取用資料的例子： int myglob = 42 ; int ml_func ( int a, int b) { return myglob + a + b; } 讓我們看看 ml_func 的反組譯：  00000000000005ec ...

作者： 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的方式對映到多個行程的虛擬記憶體)，就能夠省...