自 Rust 1.59 以降，在 Rust 代碼中內(nèi)聯(lián)匯編代碼的語言特性已然 stable^1。參考知乎上一篇文章^3，我用 Rust 的內(nèi)聯(lián)匯編實(shí)現(xiàn)了有棧協(xié)程^4。在此過程中學(xué)到了一些知識(shí)。

本文假設(shè)讀者對(duì) x86 匯編有基礎(chǔ)了解。

局部?jī)?nèi)聯(lián)匯編與自動(dòng)分配寄存器

Rust 的內(nèi)聯(lián)匯編一開始是對(duì)標(biāo) GCC 的內(nèi)聯(lián)匯編設(shè)計(jì)的，長(zhǎng)得像這樣^5：

asm!("mov $4, %eax cpuid mov %eax, $0 mov %ebx, $1 mov %ecx, $2 mov %edx, $3" : "=r"(a), "=r"(b), "=r"(c), "=r"(d) : "m"(info) : "eax", "ebx", "ecx", "edx" )

后來才變成如今富有 Rust 特色的樣子^6：

asm!( "mov edi, ebx", "cpuid", "xchg edi, ebx", in("eax") info, lateout("eax") a, out("edi") b, out("ecx") c, out("edx") d, )

與 GCC 內(nèi)聯(lián)匯編語法一樣，Rust 希望即使需要手寫匯編，程序員也能將一部分工作交給編譯器來高效完成，這部分工作就是寄存器分配，畢竟只有編譯器了解內(nèi)聯(lián)匯編前后的上下文，知道該怎么分配寄存器最合適。

asm宏的in，out，inout，lateout，inlateout參數(shù)就是為了讓編譯器幫助分配寄存器的。

in表示將變量的值傳給寄存器，編譯器生成的匯編代碼會(huì)使得在內(nèi)聯(lián)匯編代碼中讀取相應(yīng)的寄存器，就得到了傳入的變量的值；

out表示將寄存器的值寫到變量中，在內(nèi)聯(lián)匯編代碼中寫入相應(yīng)寄存器，編譯器在內(nèi)聯(lián)匯編之后生成的匯編代碼會(huì)使得相應(yīng)變量具有寫入相應(yīng)寄存器的值；

late則是代表編譯器可以采取進(jìn)一步的策略來優(yōu)化寄存器分配：默認(rèn)的分配策略給每個(gè)參數(shù)分配不同的寄存器，使用lateout或inlateout的參數(shù)則允許編譯器復(fù)用某個(gè)in參數(shù)的寄存器，只要內(nèi)聯(lián)匯編代碼中先讀完所有的in寄存器，再輸出lateout或inlateout寄存器即可。

具體細(xì)節(jié)以及此處沒講到的option可參考^1。

全局內(nèi)聯(lián)匯編與名稱修飾（Name Mangling）

除了需要寫在函數(shù)體中的asm宏，還有需要寫在函數(shù)之外的global_asm宏，其作用與獨(dú)立的匯編代碼相差不大，一切全由程序員掌控，沒有上節(jié)所述寄存器自動(dòng)分配之功能，還需要手動(dòng)管理參數(shù)傳遞，棧對(duì)齊等等。

用global_asm我們可以寫出源代碼完全是匯編代碼的函數(shù)，函數(shù)名就是匯編代碼中的標(biāo)簽，函數(shù)參數(shù)和返回值需要按照 ABI 約定來處理^7：

use std::global_asm; extern "C" { fn my_asm_add(a: i32, b: i32) -> i32; } global_asm!{ "my_asm_add:", "mov eax, edi", "add eax, esi", "ret", } fn main() { let a = 114; let b = 514; let x = unsafe { my_asm_add(a, b) }; dbg!(x); }

這段代碼在x86_64-unknown-linux-gnu的目標(biāo)，也就是 Rust Playground 的運(yùn)行環(huán)境下會(huì)通過編譯并輸出正確結(jié)果 628，但在 64 位 Windows 下則會(huì)得到錯(cuò)誤的結(jié)果，因?yàn)?64 位 Windows 所用的 C ABI 和 64 位 Linux 不一樣，雖然都是通過寄存器傳遞參數(shù)，但 64 位 Windows 的 C ABI 的第一二參數(shù)是用 RCX 和 RDX 傳遞，而非示例中的 RDI 和 RSI。

而在MacOS上編譯，結(jié)果是編譯不過——雖然和 64 位 Linux 一樣使用 System V AMD64 ABI，但 MacOS 進(jìn)行 C 語言函數(shù)名名稱修飾時(shí)會(huì)在函數(shù)名前加一個(gè)下劃線，所以編譯器會(huì)試圖尋找_my_asm_add符號(hào)，結(jié)果找不到。在匯編代碼中把"my_asm_add:"改成"_my_asm_add:"即可編譯通過。

由此可見匯編語言的不可移植性：即使是同一架構(gòu)，甚至同一 ABI 約定的匯編代碼也相當(dāng)不可移植。

在代碼編寫過程中，我發(fā)現(xiàn)一個(gè)技巧可以規(guī)避掉名稱修飾的影響。asm和global_asm宏可以接受格式為sym SYMBOL的參數(shù)來引用符號(hào)，其中SYMBOL是函數(shù)或者靜態(tài)變量，這種參數(shù)的目的是在匯編語言中直接引用 Rust 函數(shù)或靜態(tài)變量的符號(hào)，盡管 Rust 的名稱修飾算法尚未 stable，但代碼中可以不寫出來而由編譯器來計(jì)算。這個(gè)功能也可以用在extern符號(hào)上，因此可以這樣寫：

global_asm!{ ".extern {0}", "{0}:", "mov eax, edi", "add eax, esi", "ret", sym my_asm_add, }

這樣在編譯 x86_64-unknown-linux-gnu 目標(biāo)時(shí)生成的匯編代碼中的標(biāo)簽是my_asm_add，而對(duì)于x86_64-apple-darwin目標(biāo)，生成的標(biāo)簽則是_my_asm_add。

這樣的技巧不夠方便，更直觀的寫法是 naked function^9，這種函數(shù)從外部看來就是一個(gè) unsafe 函數(shù)，而內(nèi)部只允許有一個(gè)asm宏調(diào)用，編譯器不生成一般函數(shù)中會(huì)有的各種上下文代碼，函數(shù)本體完全由該 asm 宏調(diào)用生成。

程序重定位與位置無關(guān)代碼

為了加載動(dòng)態(tài)鏈接庫或者避免被黑客利用固定程序地址攻擊，操作系統(tǒng)加載程序時(shí)會(huì)將其載入到隨機(jī)的內(nèi)存地址，這個(gè)過程就是程序重定位。

對(duì)于 32 位 x86 程序，需要在加載時(shí)修改程序中所有的絕對(duì)地址，包括函數(shù)的和數(shù)據(jù)的。在匯編語言中可以直接將標(biāo)號(hào)作為常量使用，但最好不要寫mov eax, LABEL這樣的語句，因?yàn)檫@樣的語句加載器不會(huì)識(shí)別和修改。應(yīng)該寫lea eax, LABEL。

x86_64 支持相對(duì) RIP 尋址，Rust 編譯器默認(rèn)將代碼編譯為使用這項(xiàng)特性的位置無關(guān)可執(zhí)行程序（PIE），因此在 Rust 的內(nèi)聯(lián)匯編中取符號(hào)地址需要寫成lea rax, [rip+SYMBOL]。

示例，x86_64 平臺(tái)下給 static 變量X加 1 的函數(shù)用匯編語言實(shí)現(xiàn)[11]：

use std::global_asm; static mut X: usize = 0; extern "C" { fn incr_x(); } global_asm!{ "{0}:", "add dword ptr [rip+{X}], 1", "ret", sym incr_x, X = sym X, } fn main() { unsafe { incr_x(); dbg!(X); incr_x(); dbg!(X); } }

32 位 x86 代碼下則需要把匯編代碼改成：

global_asm!{ "{0}:", "lea eax, {X}", "add dword ptr[eax], 1", "ret", sym incr_x, X = sym X, }