在前一篇文章中,我們認識了 GNU 間接函式(GNU indirect function)的運作機制,然而,正如在那篇文章中說過的,使用 GNU 間接函式必須在實作解析器函式時注意許多細節,增加了使用上的難度。不過,如果只是要替特定硬體提供更快速的實作,GCC 提供了一個更方便的方法(目前只支援 x86)——函式多版本化(function multiversioning),也就是這篇文章所要介紹的。
Ernie's Blog
知其然,亦要知其所以然
2017年4月23日 星期日
2017年4月15日 星期六
GNU indirect function 的運作機制
有時候為了提高程式的效能,對於同一個函式,根據執行時的環境,我們在實作上可能會有兩種以上的選擇,在傳統的方法中,我們可能會選擇使用函式指標來做這件事,然而,管理這些函式指標通常相當麻煩,尤其是當這個函式還要提供給其他函式庫使用的時候。但在 GNU/Linux 上,我們可以在某些情況,使用另一個更方便的方法——GNU 間接函式(GNU indirect function)。
此外,GNU 間接函式也是 GCC 的函式多版本化(function multiversioning)機制的實作基礎,如果想要了解函式多版本化的運作方式,提前弄清楚 GNU 間接函式也是必要的。
在本文中,會以 x86-64 為例,解釋 GNU 間接函式的運作機制。
2017年4月3日 星期一
什麼是 Linux vDSO 與 vsyscall?——發展過程
在現今的 x86 Linux 上,無論 32 位元還是 64 位元系統,我們都可以找到 vDSO 或 vsyscall 的蹤跡,然而,在網路上卻很難找到仔細討論的文章,有時候,即便找到了一些以前的文章,在對照現今的 Linux 核心原始碼時,總會覺得這樣或那樣的似是而非,因此,我決定追溯歷史,弄清楚這些差異源自哪裡。
2017年3月17日 星期五
[翻譯] 認識 x64 程式碼模型(code model)
- 原文標題:Understanding the x64 code models
- 原文網址:http://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models
- 原文作者:Eli Bendersky
- 原文發表時間:2012 年 01 月 03 日
- 譯註:
- 文中的反組譯內容使用的是 AT&T 格式的組合語言語法。
- 關於「code model」的正體中文翻譯,有程式碼模型、程式碼模式、編碼式樣等,在本文中,一律採取「程式碼模型」。
↓↓↓↓↓↓ 正文開始 ↓↓↓↓↓↓
在撰寫用於 x64 架構程式碼的時候,一個會出現的有趣議題是要使用哪個程式碼模型(code model),儘管這可能不是一個廣為人知的主題,但如果有人想要理解編譯器所產生的 x64 機器碼,則熟悉程式碼模型就有了教育意義;而對於那些真的很在乎效能,直到每個細小指令的人來說,該主題對最佳化(optimization)也會有影響。
2017年3月7日 星期二
[翻譯] 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 理論上如何運作早已了解,一般來說,用於這兩個平台的構想是很相似的,只不過由於各個架構的獨特特性,所以某些細節會有差異。
2017年3月2日 星期四
[翻譯] 共享函式庫裡的位址無關程式碼(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 共享函式庫的這個問題有兩個主要的方式:
- 載入期重定位(load-time relocatio)
- 位址無關程式碼(position independent code,PIC)
載入期重定位已經講過了,在這裡,我要解釋第二種方式——PIC。
2017年1月8日 星期日
[翻譯] 共享函式庫的載入期重定位
- 原文標題: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。