GNU indirect function 的運作機制

有時候為了提高程式的效能，對於同一個函式，根據執行時的環境，我們在實作上可能會有兩種以上的選擇，在傳統的方法中，我們可能會選擇使用函式指標來做這件事，然而，管理這些函式指標通常相當麻煩，尤其是當這個函式還要提供給其他函式庫使用的時候。但在 GNU/Linux 上，我們可以在某些情況，使用另一個更方便的方法——GNU 間接函式（GNU indirect function）。

此外，GNU 間接函式也是 GCC 的函式多版本化（function multiversioning）機制的實作基礎，如果想要了解函式多版本化的運作方式，提前弄清楚 GNU 間接函式也是必要的。

在本文中，會以 x86-64 為例，解釋 GNU 間接函式的運作機制。

[翻譯] x64 上共享函式庫裡的位址無關程式碼（PIC）

• 原文標題：Position Independent Code (PIC) in shared libraries on x64
• 原文網址：http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64
• 原文作者：Eli Bendersky
• 原文發表時間：2011 年 11 月 11 日

↓↓↓↓↓↓ 正文開始 ↓↓↓↓↓↓

前篇文章解釋了位址無關程式碼（position independent code，PIC）是如何運作的，並以 x86 架構下編譯的程式碼作為範例，我承諾過會在一篇分開的文章中涵蓋 x64〔1〕上的 PIC，所以我們才會在這裡。本文討論的細節會少很多，因為它假定對 PIC 理論上如何運作早已了解，一般來說，用於這兩個平台的構想是很相似的，只不過由於各個架構的獨特特性，所以某些細節會有差異。

[翻譯] 共享函式庫裡的位址無關程式碼（PIC）

• 原文標題：Position Independent Code (PIC) in shared libraries
• 原文網址：http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries
• 原文作者：Eli Bendersky
• 原文發表時間：2011 年 11 月 03 日
• 譯註：
  
  • 在本文的翻譯中，section 翻譯為區段，segment 翻譯為節區，這兩個名詞的翻譯方法時有交換，我只是挑一種我喜歡的。
  • 本文圖片均取自原文網頁。

↓↓↓↓↓↓ 正文開始 ↓↓↓↓↓↓

於一篇先前的文章中，我已經敘述過當要載入共享函式庫到行程（process）的位址空間時，所需要的特殊處理，大致上，在連結器（linker）生成共享函式庫的時候，它並不能預先得知函式庫會被載入到什麼位置，而這對函式庫內的資料與程式碼參照（reference）造成了問題，它們需要以某種方式指向正確的記憶體位置。

處理 Linux ELF 共享函式庫的這個問題有兩個主要的方式：

1. 載入期重定位（load-time relocatio）
2. 位址無關程式碼（position independent code，PIC）

載入期重定位已經講過了，在這裡，我要解釋第二種方式——PIC。

[翻譯] 共享函式庫的載入期重定位

• 原文標題：Load-time relocation of shared libraries
• 原文網址：http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/
• 原文作者：Eli Bendersky
• 原文發表時間：2011 年 08 月 25 日

↓↓↓↓↓↓ 正文開始 ↓↓↓↓↓↓

本文目標為解釋現代作業系統如何在有載入期重定位（load-time relocation）的情況下使用共享函式庫（shared library），雖然它聚焦於 32 位元 x86 上的 Linux 作業系統，但這些通用原則仍適用於其他作業系統與 CPU。