GCC function multiversioning 的實現方式

在前一篇文章中，我們認識了 GNU 間接函式（GNU indirect function）的運作機制，然而，正如在那篇文章中說過的，使用 GNU 間接函式必須在實作解析器函式時注意許多細節，增加了使用上的難度。不過，如果只是要替特定硬體提供更快速的實作，GCC 提供了一個更方便的方法（目前只支援 x86）——函式多版本化（function multiversioning），也就是這篇文章所要介紹的。

什麼是 Linux vDSO 與 vsyscall？——發展過程

在現今的 x86 Linux 上，無論 32 位元還是 64 位元系統，我們都可以找到 vDSO 或 vsyscall 的蹤跡，然而，在網路上卻很難找到仔細討論的文章，有時候，即便找到了一些以前的文章，在對照現今的 Linux 核心原始碼時，總會覺得這樣或那樣的似是而非，因此，我決定追溯歷史，弄清楚這些差異源自哪裡。

[翻譯] 共享函式庫裡的位址無關程式碼（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。

[翻譯] 系統呼叫（system call）的剖析（下）

• 原文標題：Anatomy of a system call, part 2
• 原文網址：http://lwn.net/Articles/604515/
• 原文作者：David Drysdale
• 原文發表時間：2014 年 07 月 16 日

譯註：

• 本文內容與圖片皆自原網址修改。
• 根據原文使用的參考資料連結，原文應該是使用 3.14 版核心做為依據。

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

上一篇文章探索了系統呼叫（system call，或 syscall）的核心實作最平凡的形式：一個一般的系統呼叫、並在一個最普遍的架構上：x86_64。現在，用這個基本主軸的一些變體，含括了其他 x86 架構和其他系統呼叫機制，來完結我們在這方面的關注。我們要從探索各種 32 位元 x86 架構的變種開始，一張相關牽涉範圍的地圖也許對此有所幫助，這張地圖在檔案名稱和箭頭線段標籤上，都是可以點擊然後連結到被參考程式碼的：