二進制程序跨平臺移植時用戶過程的數據恢復

劉曉楠，趙榮彩，龐建民，魏振方

（1.信息工程大學四院，河南 鄭州450002；2.國家科技部 數學工程與先進計算國家重點實驗室，河南 鄭州450002）

0 引 言

二進制翻譯［1－5］是一種特殊的編譯技術，與正向編譯不同，它處理的是二進制形式的可執行程序，這樣的程序是一系列指令操作和操作所需數據的集合。以二進制翻譯形式實現的程序移植，不但要實現不同指令集架構 （instruction set architecture，ISA）之間程序語義的完全模擬，同時也必須在目標體系架構上原樣恢復程序運行時所需的所有數據。

使用C語言編寫的程序是由一個個函數 （也稱過程）構成的，經過編譯后，會生成相應的可執行程序。從宏觀上講，對這樣的可執行程序進行數據恢復，實質上是對其包含的用戶過程和庫過程中的參數、變量、常量等數據的全面移植。從微觀角度看，可執行程序是由一條條指令構成，針對指令的數據恢復就轉變為在目標平臺上原樣映射源平臺上的內存中和寄存器中的數據。

信息工程大學開發的IA64到Alpha的靜態二進制翻譯器提出基于IA64ABI（application binary interface）的參數數據的恢復方法，但并未涉及IA32架構。現有的數據恢復手段［6］一般以構造完整的控制流圖為前提，再輔以對過程實施活躍變量分析等處理。但是這類技術本身存在先天劣勢，即通過靜態分析手段不能保證獲得完備的程序控制流圖。除此以外，上述方法還存在一定的局限性，眾所周知，常用的C編譯器一般都提供不同級別的編譯優化選項優化，以常用的GCC編譯器為例，使用O3級別的優化選項編譯生成的二進制程序中已經很難再找到原有的過程參數傳遞方式的痕跡。當然采用這樣處理方式生成的二進制程序，其內存數據的棧楨布局都會與ABI的約定有所不同。因此僅僅通過控制流和數據流分析等手段不一定能解決過程調用中參數和變量的恢復問題。

用戶自定義過程的參數和變量在某些情況下是不能被完全恢復的，其恢復的程度與源代碼編譯時被優化的程度，以及馮諾依曼體系中數據與指令混存方式有關［7，8］。因此對于用戶自定義過程，本文提出了一種不同的處理方式，以達到恢復過程訪問的所有數據的目的。

1 過程訪問的數據

過程所訪問的數據主要有常量、變量，過程間傳遞的參數，其中關于常量的恢復比較簡單，本節主要描述變量和參數與數據的關系。

在高級語言中 （以C語言為例），變量如果按照定義的位置可以分為3類：全局變量、局部變量和過程參數。這3類數據在二進制翻譯中處理各不相同，本文從編譯的角度做簡要介紹：

（1）全局變量是程序高級編程語言提供的一種數據處理方式，可在當前執行程序的所有過程中對它進行訪問。通過編譯器編譯之后，全局變量所對應的存儲單元將被分配一個特定的地址空間，該空間通常處于可執行二進制文件的數據段中。

（2）與全局變量不同，局部變量的訪問范圍局限于一個過程之內。編譯器通常將局部變量放在過程調用的棧幀結構中。局部變量的生命期隨著過程調用開始而開始，隨著過程調用結束而終結。

（3）過程參數是過程調用方 （caller）與被調用方（callee）之間傳遞數據的主要手段。它通常由caller設置，編譯器按照ABI規范處理，并傳遞給callee使用。

2 本文數據恢復的相關問題和前提條件

本文在討論數據恢復方案時，有幾個相關問題需要單獨聲明：

（1）關于動態鏈接和堆中的數據遷移，本文所涉及的二進制翻譯系統在目標端采用函數封裝的方式，即使用目標平臺上同名的C 庫函數來模擬源平臺的C 庫函數調用，因此不必考慮動態鏈接和程序運行時堆數據的分配與回收。

（2）內存指針問題，本文所述二進制翻譯實現是基于匯編級映射的，即源二進制文件經過反匯編后，再經過中間表示映射到目標平臺的匯編指令，進而實現在目標平臺的翻譯的。因此不涉及內存指針的處理。

（3）大小端問題，本文所述二進制翻譯系統的源和目標平臺恰好都為小端模式，所以數據處理方式類同。即便假設存在大小端不同的情況，也可以在每次數據裝載和寫入時進行簡單轉換。因此該問題不影響本文的技術實現。

（4）虛擬內存和內存頁大小問題，關于二進制翻譯訪存范圍，本文所述系統采取與X86完全一致的低4G 內存映射方案，并且程序是匯編級別的。源和目標平臺也都是運行Linux操作系統。因此本文討論問題也不涉及虛擬內存的分配，內存頁大小也對本文所述方法無影響。

本文討論的有關用戶自定義過程的數據恢復問題是在以下前提下提出的：

（1）在二進制翻譯過程中，源文件已經被正確解碼，并已經用中間表示手段呈現。

（2）本文的數據恢復是在二進制翻譯過程中當源體系架構的程序執行空間已經映射到目標體系架構的相應地址空間之后討論的。

（3）筆者所參與的二進制翻譯系統是一個多源，單目標的動靜混合的翻譯器。下文所述例子將選取該系統支持的一種源體系結構IA32，目標選取RISC 架構的某國產CPU （下文簡稱OUR－RISC）。

（4）本文分析例子基于的C 程序源碼如圖1所示。該程序在IA32＼Linux下編譯生成可執行文件，通過二進制翻譯可以在OUR－RISC上執行。

圖1 示例程序的源碼

3 基于語義鏡像和棧幀動態維護的過程數據恢復

通過深入分析用戶自定義過程中參數和變量在二進制翻譯過程中的特性，可知不管翻譯的源和目標如何變化，被翻譯程序的語義是必須被保持的。即數據的訪問方式和存儲空間可能不容易恢復，但程序在過程調用中指令語義卻一定可以通過相關技術手段復原。因此在進行數據恢復的時候，并不進行參數和變量的準確識別和區分。而是在指令語義層面完成目標對源的精確模擬，同時還需要將指令執行過程中與數據暫存、傳遞、讀取、寫入等操作相關的寄存器和內存空間也同樣在目標端模擬。對于過程動態調用時內存數據的恢復則輔助以棧幀動態維護策略。這樣處理后，目標機器中對寄存器和內存的訪問時機和動作均與源平臺嚴格對應。

針對用戶自定義過程在執行中指令訪問數據的3種可能性，即：源機器上的數據均處于程序執行時訪問的寄存器、可執行程序的數據段以及執行時的內存楨棧中，提出了具體的應對策略：

（1）寄存器中數據的處理

對于寄存器尋址，本文采用精確映射的策略：針對源機器和目標機器的全部寄存器，如果目標機器提供的同類型寄存器數量多于源機器，為提高翻譯后程序的執行效率，對寄存器進行一對一精確映射。映射的時候需要綜合考慮不同指令集架構ISA 寄存器的類型和屬性。如果目標機器寄存器數量少于源機器，在部分寄存器采用精確映射的基礎上，其余寄存器可以通過內存模擬 （在內存中開辟固定區域，對被映射的寄存器內容的全部變化完全模擬，稱作全態模擬）；若源和目的機器的寄存器數量相同，由于不同機器對寄存器的設定差異，一般也應該采用精確映射與全態模擬相結合的策略。

在二進制翻譯中，不同的ISA 通常使用不同的參數傳遞策略，例如：多數64位ISA 選擇通過寄存器傳遞前幾個參數，超過約定參數個數后，將使用內存傳參的方式；而32位的X86就只使用內存來傳遞參數。實際應用中需要靈活處理。

（2）數據段中數據的處理

可執行程序數據段中的數據屬于靜態數據。靜態數據一般是源代碼經過編譯后被有組織的放在程序的數據段中，包括被靜態初始化的全局變量、數組等。針對數據段中的數據，在二進制翻譯中，可以采用數據段克隆的方式在二進制的目標文件中重建。

（3）運行時內存數據的處理

動態數據，通常指存在于程序被執行時堆中和棧中的數據。堆中的數據一般是通過調用內存申請庫函數而在程序執行時獲得空間并使用的。因此對于堆中的動態數據，不需要進行恢復。但是對于棧中的數據，該部分數據與可執行程序運行時過程的調用和返回息息相關，必須通過全態模擬與棧幀動態維護相結合的方式進行數據的恢復。

3.1 基于語義鏡像的數據恢復

寄存器中的數據在程序運行時，一般是通過寄存器名稱來訪問的，如語句 “sub esp，18h”。在設計中間語言時，通過對寄存器進行編號，前邊的匯編語句就變成 “r28＝r28－24”。最終翻譯到目標平臺就變成了 “ldi＄sp，－24（＄sp）”。針對寄存器類型的數據，需要采用上文提到的精確映射的解決策略。

而對于存儲在數據段中的數據，則通常是根據編譯程序分配的固定內存地址來訪問，如語句 “push x”（其中的x是一個在.data段的全局變量x，初值是3，其數據段的描述為 “.data：08049450public x .data：08049450x dd 3）”。轉換 成 中 間 語 言 就 變 成 了 “m ［r28－4］：＝m［0x8049450］”。最終翻譯到目標平臺，由后邊的4條語句完成“ldi＄5，0x8049450；ldw ＄5，0 （＄5）；stw ＄5，－4（＄sp）；ldi ＄sp，－4 （＄sp）；”。可見程序執行時是根據編譯器分配的固定地址0x8049450來讀取處于數據段中的全局變量x的值3，然后再把數值3壓棧。針對這種對數據的訪問形式，需要采用上文提到的數據段克隆的解決策略。

基于語義鏡像的數據恢復就是采用了精確映射和數據段克隆結合的手段，只要保證鏡像后目標平臺的指令在語義層面與源平臺完全等價，就可以準確完成數據的恢復。接下來對語義鏡像的具體實現通過實例給出介紹。

3.1.1 針對寄存器的精確映射

寄存器的映射是二進制翻譯過程中的重要步驟，其映射的過程絕對不是簡單的牽線對應，而是建立在對源和目標機器ISA 深刻理解的基礎上，精確映射方案的確定需要通盤考慮準確性和效率。想要在目標機器準確模擬源機器的行為，可以將源機器的寄存器與目標機器的寄存器建立映射關系。當然由于源和目標ISA 的差異有時難以彌合，在有些時候也可以選擇將源機器的寄存器映射到目標機器的某段內存空間，通過內存模擬的方式消除較大的體系結構差異。考慮到程序運行中頻繁訪存的開銷，只要目標機器的寄存器數量和資源較多，絕大多數情況下都采取寄存器間的精確映射方式［9，10］。

在我們的實例中，源機器采用最為常見的32 位X86（也就是IA32架構），目標機器為某RISC 架構處理器，提供了豐富的寄存器資源，完全可以勝任針對X86處理器的精確映射，精確映射策略是二進制翻譯獲得較高性能的首選做法。

示例分析：

IA32架構的基本寄存器如圖2所示。通用寄可以整體32位使用，也可以單獨使用其16位或者8位，方式比較靈活，如圖3所示。

（1）IA32通用寄存器精確映射

如表1所示在中間表示層和目標處理器層均對寄存器標稱了相應的編號。工程應用中，開發者應該明確寄存器編號與物理寄存器的對應關系。其中序號的起止并不是重要的問題，選擇序號的起止范圍與工程實踐中具體細節有關，其方式也比較靈活，表1也只是給出一種示例方案。

圖2 IA32通用寄存器

圖3 通用寄存器的復用

表1 精確映射方案

寄存器Caller－save和Callee－saved屬性的處理：在精確映射過程中特別需要注意調用者／被調用者保存寄存器（caller／callee saved registers），IA32 中 兩 種 寄 存 器 屬 性 的分布見表1。需要注意的是主調過程caller在過程調用前不保存callee－saved寄存器的值，這一點在IA32程序正常執行的時候不存在任何問題，編譯器和操作系統會進行自動的處理。但是在二進制翻譯過程中，目標平臺的程序調用約定不同。假如被調用過程是庫函數，如果被調用的庫函數改變了本應在IA32 平臺下被callee－saved處理的寄存器值，勢必導致二進制翻譯程序的執行錯誤。因此必須在精確映射時將callee－saved寄存器映射到目標平臺的受保護寄存器 （preserved across procedure calls），本所所針對目標平臺的受保護寄存器與X86平臺 “callee－saved”在功能和含義上都是一致的。

針對需要由調用者保存的寄存器，其保存動作一般可以通過指令語義分析很容得的獲得。以X86架構為例，過程調用者會在調用發生之前通過一組組的數據壓棧指令完成對寄存器的保存操作。下文要提及的全態模擬處理方式可以將顯式的指令操作在目標機器重現，所以源機器的caller－saved寄存器在映射時不需要區分目標寄存器的類型。

特殊功能寄存器的處理：源平臺的ESP寄存器一般在堆棧尋址時使用，所以被特別精確映射到目標平臺功能相近的＄sp寄存器中；而擴展棧指針寄存器ESP同樣被精確映射到目標平臺的功能相近＄fp寄存器中。

IA32架構通用寄存器可以部分訪問的處理：IA32架構為了保持對歷史架構的兼容等原因，對于EAX 等寄存器允許訪問低16位AX 寄存器，以及8位的AH 和AL 寄存器的情況。而目標平臺的RISC架構只允許對寄存器整體的訪問，因此還需要額外使用目標平臺的移位、置位、異或等指令做相應處理以彌合不同體系結構之間的差異。這些功能被稱為精確映射的配套處理過程。

（2）IA32架構的EFLAGS

關于EFLAGS寄存器在二進制翻譯中的處理是比較復雜的，相關文獻 ［11，12］中有對應的論述。筆者參與的二進制翻譯系統中，除了對該寄存器采取精確映射和活躍狀態模擬之外，還使用了大量的優化、模擬，以及化簡算法，其涉及的內容已經超出本文討論的范圍。而與精確映射有關的就是需要指定目標平臺的一個寄存器來承擔EFLAGS寄存器的功能。

（3）其它寄存器的處理

由于源和目標架構存在地址空間轉換問題，所以在指令解碼階段提前將指令指針寄存器EIP 的偏移尋址的地址轉化為目標平臺可用的固定地址，因此也就不需要對EIP進行精確映射和模擬了。同時考慮到在IA32架構下高級語言編制的可執行程序在反匯編解碼后，不會出現對段寄存器的操作，所以無需對6 個16 位的段寄存器進行任何處理。而對于浮點寄存器，我們采用在中間代碼生成時就通過多條中間代碼對IA32架構中棧式的浮點寄存器變化過程做了全態模擬，所以浮點寄存器也只需要進行一對一的精確映射即可：ST（0）－ST（7）依次映射到目標平臺的＄f2－＄f9這8個受保護的浮點寄存器。

3.1.2 數據段克隆

數據段克隆是指為降低不同平臺間二進制翻譯數據移植的難度，采取特定處理方法和映射策略將源平臺可執行程序的數據段整體克隆到目標平臺的相應可執行程序中。下面通過簡單的示例來大體說明其具體做法，示例程序為IA32＼Linux環境下的ELF32格式的可執行文件作。

示例分析：

可執行文件格式 （executable and linking format，ELF）文件是Linux 操作系統下的一種常用目標文件 （object file）格式，如圖4所示。

圖4 ELF文件結構

通過分析ELF32文件的程序頭部中為每個section保存的段描述符，我們可以區分section類型，定位與數據存儲相關的幾個section在文件中的偏移、大小，以及需要被映射到的虛擬地址。據此可以把section中的數據按需提取出來，作為數據段克隆的源數據。

由于源平臺的程序在編譯后，生成的可執行二進制程序中section會被映射到 “固定”的虛擬空間 （既段的虛擬地址不變，比如例子中的.rodata 就被映射到虛擬地址0x8048430，大小為8個字節，如圖5 所示）。ELF 程序對數據段中數據的訪問也是通過相應的虛擬地址給出：對函數printf的格式字符參數 “z＝%d”的訪問，就是通過給出標號format（該標號對應虛擬地址0x8048438）的方式訪問。

圖5 示例文件中.rodata段內容

由此可見，如果將提取出的數據段源數據 “克隆”到目標機器中，也就是保證翻譯后的程序在目標機編譯后，仍然可以將.rodata等數據段加載到與源機器同樣的虛擬地址處，我們采用的方式可用圖6的偽代碼描述。同時將可執行程序的運行地址空間范圍原樣克隆到的目標機對應虛擬空間中，就可以保證翻譯得到的目標代碼根據虛擬地址直接訪問這些數據。

圖6 實現數據段克隆的偽代碼

圖6中對源體系架構處于數據段中的數據通過在中翻譯程序使用字符數組，并配合內存數據移動的手段實現了對預案體系架構數據段的克隆操作。但是這種處理方法在應用程序的數據段容量極大時是存在缺陷的，因為有的高級語言對字符數組的大小是有限制的。因此需要進行一定的調整。即首先在二進制翻譯時將源二進制文件中數據段寫入文件。然后當被翻譯程序執行時，提前將被寫入文件的數據加載到特定的內存空間。被翻譯程序在執行時則通過數據偏移的方式按需訪問這些靜態數據即可。

3.2 棧幀動態維護實現數據的恢復

3.2.1 棧幀布局

程序運行時的重要數據結構——棧幀 （stack frames），主要用于過程調用的數據保存和恢復，通常用它來保存臨時變量，過程調用需要的傳遞參數和返回值等數據，以及提供一些需要臨時分配的空間。

承接上文的示例，我們仍然以IA32 架構的Stack Frame來舉例，包含一個調用者棧幀 （caller stack frame）和一個被調用過程的棧幀 （也就是當前執行過程的棧幀current stack frame），如圖7所示。在圖7中有兩個重要的指針，分別是棧指針，其值為寄存器ESP 的值 （stack pointer，SP）和幀指針，其值為寄存器EBP 的值 （frame pointer，FP）。

3.2.2 棧幀動態維護

圖7 棧幀內存布局

過程調用中參數的傳遞和調用結束后的返回都是通過棧的方式完成。如果callee要訪問參數數據，caller要訪問返回值數據，需要首先根據要訪問數據相對于棧頂的偏移計算出其存儲地址，然后再訪問。由于各體系架構ABI規定不同，在發生過程調用時系統對過程返回地址保存方法也不盡相同。以IA32架構的處理器為例，系統在callee被調用前會將其返回地址以4 個字節的大小壓入棧頂，當callee執行結束需要返回caller時則根據事先壓入的返回地址完成控制流的轉移。而與此不同的是OUR－RISC 平臺在過程調用返回時，使用專用寄存器來保存返回值。也就是說其過程調用時不會為返回值而自動改變SP值，也不會顯式的將返回地址壓棧。針對這種情況，如果僅僅是在翻譯過程中簡單的進行指令的翻譯，則意味著目標平臺的棧指針偏移與源平臺存在差異，因為它并不需要經過程返回地址壓棧。即如果不對該差異加以處理，勢必會造成翻譯后程序在反問過程參數時出錯。因此這種由體系結構差異造成的棧指針偏差必須在二進制翻譯過程中修正。針對本文所述方法，只需將在目標端發生過程調用時自動將棧頂指針做算術加減操作即可，以此保證源和目標ISA 的不同特性不會帶來的棧幀失衡。

針對這種情況，本文提出了一個以棧幀動態維護來解決棧幀失衡的方法：在OUR－RISC 被調用過程callee的開始階段添加一個棧指針減4的操作，同時在過程返回前添加一個棧指針加4的動作。以此來模擬IA32可執行程序在過程調用時幀棧變換的全部狀態。

上文提到為了保證幀棧平衡而添加的指針加減4操作，相當于在目標平臺的用戶自定義函數開始時申請了4個字節的棧空間，而在過程返回前釋放這4 個字節的棧空間。需要指出的是，我們在具體的工程實踐中并沒有浪費這4個字節的空間。由于目標平臺的返回地址寄存器是需要callee保護的，所以可以假設如果callee在運行過程中，其內部又發生了一次過程調用，導致原來的callee身份成為了新的caller（稱為new＿caller）。這就意味著callee要翻譯到原來的caller的返回地址可能會被新的過程調用所覆蓋，導致返回出錯，程序執行失敗。上述假設在目標平臺正常的程序執行時是不會發生的，因為返回寄存器的保存由操作系統實現。但是如果是通過二進制翻譯后的程序在目標機器上執行，就有可能出現假設中的情況。因此我們利用了為了實現幀棧平衡而冗余的幀棧加減4操作，除了調整棧指針值外，還切實的將用戶自定義過程的返回地址壓棧。經過這樣的處理，就可以很完善的解決IA32 和OUR－RISC的ISA 差異給程序訪問動態數據所帶來的問題。

4 實驗結果分析

本文提出的用戶過程數據恢復方案在課題組的二進制翻譯系統中得到應用，且針對Spec2006測試集的所有程序都實現了IA32到OUR－RISC的二進制翻譯。翻譯后的程序經過編譯后，可以在OUR－RISC＼Linux正確的執行。測試結果見表2。測試內容包括翻譯程序執行輸出結果與Spec2006源程序在IA32＼Linux環境下直接執行結果對比。運行時間比率：源程序執行時間／翻譯程序執行時間＝比率。

表2 實驗結果

5 結束語

本文針對二進制翻譯中的難點——數據恢復的問題展開分析和討論，對用戶過程中涉及的函數參數、局部變量、全局變量以及返回值等數據在目標平臺上完成了相應的恢復。實驗結果表明，該方法即可以保證翻譯程序運行結果正確，同時又能使得被翻譯程序具有較高的執行效率，實現了IA32程序所用數據移植到OUR－RISC 處理器的目標。下一步的研究工作將集中在對二進制翻譯生成程序執行效率的進一步提升之上。

［1］ZHANG Yaoxue.Thoughts on China’s infrastructure software and development of China’s CPU ［R］.Hangzhou：China Computer Federation，2010 （in Chinese）.［張堯學.關于我國基礎軟件與CPU 發展的幾點思考 ［R］.杭州：中國計算機學會，2010.］

［2］CAI Songsong，LIU Qi，WANG Jian，et al.Optimization of binary translator based on godson CPU ［J］.Computer Engineering，2009，35 （7）：280－282 （in Chinese）. ［蔡嵩松，劉奇，王劍，等.基于龍芯處理器的二進制翻譯器優化 ［J］.計算機工程，2009，35 （7）：280－282.］

［3］ZHANG Ji，LI Ningbo.Key technology research of simulator based on binary translation ［J］.Computer Engineering，2010，36 （16）：246－248 （in Chinese）.［張激，李寧波.基于二進制翻譯的仿真器關鍵技術研究 ［J］.計算機工程，2010，36（16）：246－248.］

［4］Wondracek G，Comparetti PM，Kruegel C，et al.Automatic network protocol analysis［C］／／Proceedings of the 15th Annual Network and Distributed System Security Symposium，2008.

［5］Wang Z，Jiang X，Cui W，et al.ReFormat：Automatic reverse engineering of encrypted messages［C］／／Proceedings of the European Symposium on Research in Computer Security，2009.

［6］FANG Xia，YIN Qing，JIANG Liehui，et al.Register parameter recovery method based on dataflow analysis ［J］.Computer Engineering，2009，35 （22）：62－64 （in Chinese）. ［方霞，尹青，蔣烈輝，等.基于數據流分析的寄存器參數恢復方法 ［J］.計算機工程，2009，35 （22）：62－64.］

［7］ZHANG Youwei，LIU Xiaochun，WANG Yonghong.Study of recognition algorithm for program section ［J］.Computer Engineering，2009，35 （5）：72－73 （in Chinese）. ［張有為，劉小春，汪永紅.程序段識別算法研究 ［J］.計算機工程，2009，35 （5）：72－73.］

［8］Mike Van Emmerik.Static single assignment for decompilation［M］.USA：The University of Queensland School of Information Technology and Electrical Engineering，2007.

［9］WEN Yanhua，TANG Daguo，QI Fengbin.Register mapping and register function cutting out implementation in binary translation ［J］.Journal of Software，2009，20 （zk）：1－7 （in Chinese）.［文延華，唐大國，漆鋒濱.二進制翻譯中的寄存器映射與剪裁的實現 ［J］.軟件學報，2009，20 （zk）：1－7.］

［10］LIAO Yin，SUN Guangzhong，JIANG Haitao，et al.All registers direct mapping method in dynamic binary translation［J］.Computer Applications and Software，2011，28 （11）：21－24 （in Chinese）. ［廖銀，孫廣中，姜海濤，等.動態二進制翻譯中全寄存器直接映射方法 ［J］.計算機應用與軟件，2011，28 （11）：21－24.］

［11］ WANG Ronghua，MENG Jianyi，CHEN Zhijian，et al.Condition code optimization in dynamic binary translation ［J］.Journal of Zhejiang University（Engineering Science），2014，48 （1）：124－129 （in Chinese）.［王榮華，孟建熠，陳志堅，等.動態二進翻譯中的標志位優化算法 ［J］.浙江大學學報（工學版），2014，48 （1）：124－129.］

［12］TANG Feng，WU Chenggang，FENG Xiaobing，et al.Ef－LA algorithm based on dynamic feedback ［J］.Journal of Software，2007，18 （7）：1603－1611 （in Chinese）. ［唐鋒，武成崗，馮曉兵，等.基于動態反饋的標志位線性分析算法［J］.軟件學報，2007，18 （7）：1603－1611.］