高艷鹍，劉 華，劉朝暉

（1.北京計(jì)算機(jī)技術(shù)及應(yīng)用研究所，北京 100039；2.南華大學(xué)，湖南 衡陽(yáng) 421001）

0 引言

傳統(tǒng)的微處理器不適用于進(jìn)行數(shù)字信號(hào)處理所需要的高等數(shù)學(xué)運(yùn)算，其運(yùn)算需要較長(zhǎng)的計(jì)算時(shí)間，不能滿(mǎn)足現(xiàn)代信號(hào)實(shí)時(shí)處理的要求。而DSP所具有的系統(tǒng)構(gòu)成靈活、可編程、使用面廣的特點(diǎn)，使其在通信、航空航天、醫(yī)療儀器、工業(yè)控制及信息家電中成為不可或缺的數(shù)字信息處理的計(jì)算引擎。TMS320C6678（簡(jiǎn)稱(chēng)C6678）是美國(guó)德州儀器（Texas Instrument）于2011年10月推出的一款高性能浮點(diǎn)嵌入式數(shù)字信號(hào)處理器（DSP）[1]。作為一款8核的DSP，C6678可以滿(mǎn)足在軍事、工業(yè)等領(lǐng)域的實(shí)時(shí)數(shù)據(jù)處理的性能要求。C6678提供了多種芯片外設(shè)接口，支持多樣化總線(xiàn)協(xié)議，包括RapidIO、PCIe、I2C、EMIF、UART、SPI總線(xiàn)及千兆網(wǎng)，GPIO、TSIP等[2]。

天熠嵌入式操作系統(tǒng)彈載版是航天二院706所針對(duì)彈上計(jì)算機(jī)開(kāi)發(fā)的嵌入式操作系統(tǒng)產(chǎn)品，目前針對(duì)TI的C6000系列DSP能夠支持C6713、C6672、C6678，提供多種基礎(chǔ)的內(nèi)核服務(wù)。目前，使用TI公司的TMS系列通用DSP處理器做系統(tǒng)開(kāi)發(fā)需要使用專(zhuān)門(mén)的開(kāi)發(fā)工具CCS，通過(guò)JTAG接口的仿真器將程序下載到目標(biāo)機(jī)調(diào)試運(yùn)行。在某些比較復(fù)雜的應(yīng)用背景下，需要將用戶(hù)應(yīng)用程序通過(guò)靜態(tài)鏈接生成一個(gè)獨(dú)立的可執(zhí)行鏡像下載執(zhí)行，用戶(hù)每次修改一行程序都需要將整個(gè)程序重新編譯下載。當(dāng)可執(zhí)行程序較大時(shí)，下載過(guò)程就會(huì)消耗用戶(hù)較長(zhǎng)的時(shí)間，效率不高。

在商業(yè)的VxWorks操作系統(tǒng)上已經(jīng)針對(duì)X86、PowerPC等處理器實(shí)現(xiàn)了應(yīng)用程序軟件模塊的動(dòng)態(tài)加載機(jī)制，先將內(nèi)核運(yùn)行起來(lái)，然后通過(guò)內(nèi)核加載應(yīng)用程序。當(dāng)應(yīng)用程序修改后，也只需要先卸載已經(jīng)在系統(tǒng)中的該軟件模塊，再重新加載模塊，大大提高了開(kāi)發(fā)的效率。動(dòng)態(tài)加載機(jī)制的核心技術(shù)是延遲鏈接，涉及到處理器的體系結(jié)構(gòu)、編譯器技術(shù)、可執(zhí)行程序的ABI（Application Binary Interface）三方面內(nèi)容，目前業(yè)界尚未有商用的操作系統(tǒng)能夠針對(duì)TI的DSP處理器平臺(tái)提供動(dòng)態(tài)加載機(jī)制。為在彈載領(lǐng)域滿(mǎn)足用戶(hù)的使用，在基于TI C6678 DSP處理器的天熠嵌入式操作系統(tǒng)中增加動(dòng)態(tài)加載機(jī)制做了技術(shù)探索，并研發(fā)了動(dòng)態(tài)加載器作為天熠嵌入式操作系統(tǒng)產(chǎn)品組件。

1 嵌入式系統(tǒng)中軟件模塊動(dòng)態(tài)加載的使用需求分析

1.1 軟件產(chǎn)品的集成需求

隨著設(shè)備集成度越來(lái)越高，功能越來(lái)越復(fù)雜，在一個(gè)設(shè)備上運(yùn)行的軟件往往需要不同的廠商提供軟件模塊一起配合運(yùn)行，各模塊提供的服務(wù)往往又需要被其他模塊調(diào)用，例如模塊A作為主體應(yīng)用模塊需要調(diào)用模塊B提供的濾波計(jì)算服務(wù)，調(diào)用模塊C提供的設(shè)備服務(wù)，模塊B在執(zhí)行濾波計(jì)算時(shí)又需要操作系統(tǒng)提供的內(nèi)存服務(wù)接口的存儲(chǔ)器分配功能。

傳統(tǒng)的開(kāi)發(fā)方式需要在軟件開(kāi)發(fā)時(shí)將不同的軟件模塊靜態(tài)鏈接成一個(gè)單獨(dú)的可執(zhí)行程序并下載到目標(biāo)機(jī)上[3]。該方式的一個(gè)缺陷是需要不同的廠商提供對(duì)應(yīng)模塊的源碼，基于知識(shí)產(chǎn)權(quán)的保護(hù)，廠商一般會(huì)將源碼封裝為靜態(tài)庫(kù)的形式提供給主程序的研制方，但需要幾方廠商必須同時(shí)開(kāi)發(fā)完成并提交成果，否則將無(wú)法編譯鏈接[4]。在開(kāi)發(fā)時(shí)不同廠商軟件產(chǎn)品的難度，需要的資源往往無(wú)法協(xié)調(diào)一致，進(jìn)度無(wú)法保證，作為需要使用其他模塊的主應(yīng)用則無(wú)法構(gòu)建出一個(gè)完整的可執(zhí)行應(yīng)用，及早地開(kāi)展自己這部分的測(cè)試工作。軟件模塊獨(dú)立運(yùn)行視圖和傳統(tǒng)靜態(tài)鏈接的程序運(yùn)行視圖如圖1。

圖1 兩種運(yùn)行方式視圖對(duì)比Fig.1 Comparison of two operation modes

1.2 工程中程序升級(jí)方面的需求

通常在調(diào)試階段，程序開(kāi)發(fā)人員對(duì)DSP進(jìn)行編程。首先，是在PC機(jī)上使用DSP廠商提供的調(diào)試開(kāi)發(fā)軟件平臺(tái)編譯程序，而后通過(guò)DSP板的JTAG調(diào)試接口將程序下載到DSP中運(yùn)行。在實(shí)際應(yīng)用中，通常需要將DSP程序固化在DSP板上FLASH或者EEPROM中，系統(tǒng)上電后，程序自動(dòng)從FLASH中加載至DSP內(nèi)部存儲(chǔ)區(qū)并且執(zhí)行。但上述這兩種方法都需要使用額外的JTAG線(xiàn)來(lái)連接主機(jī)和DSP板，對(duì)于已經(jīng)裝配完畢的密封設(shè)備，如果需要更改程序，必須將設(shè)備進(jìn)行拆裝，重新安裝JTAG線(xiàn)進(jìn)行調(diào)試[5]。從工程應(yīng)用的角度來(lái)看，頻繁地對(duì)已經(jīng)裝配完畢的設(shè)備進(jìn)行拆裝，會(huì)嚴(yán)重影響整個(gè)系統(tǒng)的穩(wěn)定性和可靠性。為了避免這種情況的發(fā)生，應(yīng)選擇在不拆裝設(shè)備的同時(shí)遠(yuǎn)程對(duì)DSP板上程序進(jìn)行動(dòng)態(tài)加載[6]。

現(xiàn)階段，基于現(xiàn)有的同外部設(shè)備連接的總線(xiàn)接口進(jìn)行程序下載的主要技術(shù)實(shí)現(xiàn)通過(guò)在目標(biāo)機(jī)上固化一小段引導(dǎo)程序bootloader，啟動(dòng)后引導(dǎo)程序負(fù)責(zé)目標(biāo)機(jī)的運(yùn)行環(huán)境的初始化，并通過(guò)外部設(shè)備接口（一般為串口）同宿主機(jī)進(jìn)行交互，下載應(yīng)用程序并固化到Flash上，并通過(guò)跳轉(zhuǎn)語(yǔ)句將處理器執(zhí)行的控制權(quán)交給應(yīng)用程序[7]。

該種方式確實(shí)可以滿(mǎn)足應(yīng)用程序升級(jí)的需求，但有兩點(diǎn)不足：第一點(diǎn)是引導(dǎo)程序和應(yīng)用程序?qū)?nèi)存的使用布局需要在開(kāi)發(fā)時(shí)通過(guò)鏈接腳本協(xié)同規(guī)劃，從而兩個(gè)程序相互依賴(lài)；第二點(diǎn)是被加載的對(duì)象只能是獨(dú)立的可執(zhí)行應(yīng)用程序，bootloader無(wú)法加載多個(gè)應(yīng)用[8]。

1.3 對(duì)高可靠的控制計(jì)算機(jī)系統(tǒng)提供動(dòng)態(tài)升級(jí)、故障恢復(fù)的技術(shù)手段

在一些高可靠的控制計(jì)算機(jī)系統(tǒng)設(shè)計(jì)階段會(huì)提出可重構(gòu)設(shè)計(jì)需求，完成功能定制、動(dòng)態(tài)升級(jí)、故障恢復(fù)。目前，筆者接觸到的對(duì)于長(zhǎng)期在軌運(yùn)行的星載計(jì)算機(jī)領(lǐng)域?qū)υ撔枨笥葹槠惹小＠?，某星載設(shè)備的相機(jī)控制系統(tǒng)是針對(duì)地面物體進(jìn)行拍攝的高端相機(jī)的核心控制部件，相機(jī)對(duì)調(diào)焦的控制算法需要根據(jù)地物高度、衛(wèi)星在軌位置、速度、姿態(tài)等相關(guān)因素計(jì)算調(diào)焦距離[9]。由于是首次研制，缺少歷史的相關(guān)試驗(yàn)數(shù)據(jù)，對(duì)最終的相機(jī)成像效果通過(guò)地面試驗(yàn)及仿真不能充分有效驗(yàn)證，無(wú)法確定在衛(wèi)星發(fā)射后載荷相機(jī)對(duì)地面物體的成像能否達(dá)到預(yù)定的目標(biāo)?；诖耍兄品皆O(shè)計(jì)了相機(jī)控制系統(tǒng)的在軌升級(jí)機(jī)制，相機(jī)的控制系統(tǒng)使用的C5000的DSP處理器，上電啟動(dòng)后先運(yùn)行一段引導(dǎo)程序，由引導(dǎo)程序判斷是否從遙測(cè)控制接收到對(duì)控制程序的在軌更新命令。當(dāng)接收到命令時(shí)，更新核心的控制程序[10]。但設(shè)計(jì)中存在一個(gè)不足：需要控制計(jì)算機(jī)的重新上電，運(yùn)行引導(dǎo)程序。

1.4 在TI C6000 DSP構(gòu)成的嵌入式系統(tǒng)中引入基于動(dòng)態(tài)鏈接機(jī)制的動(dòng)態(tài)加載解決方案

通過(guò)以上幾點(diǎn)分析，在由TI C6000 DSP構(gòu)成的復(fù)雜、高可靠嵌入式系統(tǒng)中引入基于動(dòng)態(tài)鏈接機(jī)制的動(dòng)態(tài)加載解決方案有多方面的工程需求。在以天熠嵌入式操作系統(tǒng)彈載版的基礎(chǔ)上，開(kāi)展了研究和設(shè)計(jì)。

2 動(dòng)態(tài)鏈接原理分析

2.1 編譯器支持

完成動(dòng)態(tài)加載及鏈接牽涉不同方面的計(jì)算機(jī)技術(shù)，其中一個(gè)必要條件是編譯器必須能夠支持生成延遲重定位的目標(biāo)程序。這需要編譯器在編譯時(shí)能夠暫時(shí)屏蔽掉未定址的符號(hào)而不會(huì)報(bào)編譯錯(cuò)誤，同時(shí)為生成地址無(wú)關(guān)的代碼要插入特定的樁代碼形式或過(guò)程鏈接表。該目標(biāo)程序同可執(zhí)行程序的區(qū)別是可執(zhí)行程序是完全具備執(zhí)行能力的程序，不需要任何其他模塊輔助支持。而動(dòng)態(tài)庫(kù)程序本身不具備執(zhí)行能力，其中存在引用的符號(hào)處于未定址的狀態(tài)，如果強(qiáng)制執(zhí)行，則處理器會(huì)進(jìn)入到異常狀態(tài)。

根據(jù)TI的編譯器手冊(cè)說(shuō)明能夠生成支持動(dòng)態(tài)鏈接庫(kù)的ELF文件格式的編譯器版本應(yīng)至少為7.2以上。目前國(guó)內(nèi)針對(duì)C6000處理器使用的開(kāi)發(fā)環(huán)境主要為CCS3.3和CCS5.5。其中，CCS3.3中使用的Cl6x編譯器版本為6.08，CCS5.5的Cl6x編譯器版本為7.4，基于CCS3.3開(kāi)發(fā)環(huán)境無(wú)法實(shí)現(xiàn)動(dòng)態(tài)鏈接庫(kù)生成。

2.2 EABI文件格式支持

動(dòng)態(tài)鏈接庫(kù)的加載過(guò)程緊密依賴(lài)于TI定義的EABI（ELF Application Binary Interface）文件格式。該格式是TI公司根據(jù)標(biāo)準(zhǔn)ELF文件格式自定義的一種文件格式，依據(jù)其標(biāo)準(zhǔn)定義主要分為3類(lèi)，具體見(jiàn)表1。

表1 ELF文件的主要類(lèi)型Table 1 Main types of ELF files

目前，可使用的文件格式為共享目標(biāo)文件。從連接和運(yùn)行的角度，可以分別把目標(biāo)文件的組成部分劃分為以下兩種視圖，具體如圖2。

圖2 連接視圖和運(yùn)行視圖對(duì)比Fig.2 Comparison of connection view and operation view

表2為ELF文件格式中各段的作用，在實(shí)際加載過(guò)程都是以“段”作為處理對(duì)象。

表2 ELF文件格式的各段作用和說(shuō)明Table 2 Functions and descriptions of each paragraph of ELF file format

2.3 動(dòng)態(tài)鏈接過(guò)程

目標(biāo)模塊被加載到內(nèi)存空間后，不能立即運(yùn)行。動(dòng)態(tài)加載機(jī)制還須對(duì)目標(biāo)模塊進(jìn)行處理，解決模塊的外部引用（符號(hào)解析）和重定位，這一步是動(dòng)態(tài)加載過(guò)程中的最關(guān)鍵環(huán)節(jié)。由于模塊是被單獨(dú)編譯成共享目標(biāo)文件，因而在生成目標(biāo)文件時(shí)，調(diào)用的其他模塊或函數(shù)庫(kù)中的函數(shù)和全局變量（統(tǒng)稱(chēng)為符號(hào)）的地址仍處于不確定狀態(tài)。以對(duì)全局函數(shù)的引用舉例說(shuō)明編譯器插入的stub形式及重定址過(guò)程。源碼如下，import關(guān)鍵字標(biāo)識(shí)其為導(dǎo)入的符號(hào)，其作用是指示編譯器該符號(hào)需要加載時(shí)綁定地址。

該源碼編譯成add.dll后查看其反匯編的代碼：

在目標(biāo)模塊中，對(duì).plt段中sym符號(hào)的地址以0x0000的形式寫(xiě)入到MVK指令的地址碼，并通過(guò)B10寄存器直接尋址跳轉(zhuǎn)到sym函數(shù)，而.text段中add函數(shù)對(duì)sym符號(hào)的引用通過(guò)對(duì).plt段的相對(duì)尋址訪問(wèn)（兩個(gè)端加載后的相對(duì)偏移量保持不變）。在重定址時(shí)只需根據(jù)sym符號(hào)的實(shí)際地址和記錄的引用位置修改MVK指令的地址碼。

3 天熠操作系統(tǒng)動(dòng)態(tài)加載器的設(shè)計(jì)實(shí)現(xiàn)

3.1 動(dòng)態(tài)加載器的總體設(shè)計(jì)

3.1.1 動(dòng)態(tài)加載器的分層設(shè)計(jì)

動(dòng)態(tài)加載管理采用分層式設(shè)計(jì)，由用戶(hù)接口層、管理層、執(zhí)行層3個(gè)層次組成，如圖3。

圖3 動(dòng)態(tài)加載器的分層結(jié)構(gòu)Fig.3 Hierarchical structure of dynamic loader

1）用戶(hù)接口層：負(fù)責(zé)同用戶(hù)進(jìn)行交互的界面，提供用戶(hù)關(guān)于動(dòng)態(tài)加載相關(guān)命令的輸入、解析、執(zhí)行，具體見(jiàn)表3。

表3 用戶(hù)接口的主要命令集合Table 3 Main command sets of user interface

2）管理層：管理層主要利用內(nèi)核提供的多種服務(wù)加載模塊，對(duì)加載模塊的ELF文件格式有效性進(jìn)行判斷，保存和維護(hù)模塊的相關(guān)信息，并形成加載模塊的關(guān)系鏈表。

3）執(zhí)行層：主要負(fù)責(zé)對(duì)加載模塊外部引用的全局符號(hào)進(jìn)行重定位，完成動(dòng)態(tài)鏈接過(guò)程。

3.1.2 與天熠操作系統(tǒng)內(nèi)核其他服務(wù)的關(guān)系

考慮到天熠嵌入式操作系統(tǒng)自身的微內(nèi)核架構(gòu)，動(dòng)態(tài)加載器在設(shè)計(jì)上規(guī)劃為一個(gè)獨(dú)立的操作系統(tǒng)組件，可以跟隨系統(tǒng)進(jìn)行功能裁剪，并充分利用天熠操作系統(tǒng)已有的系統(tǒng)服務(wù)完成動(dòng)態(tài)加載器的設(shè)計(jì)，如圖4。

圖4 內(nèi)核組件服務(wù)的調(diào)用過(guò)程Fig.4 Calling process of kernel component service

Shell組件先使用網(wǎng)絡(luò)組件提供的ftp服務(wù)、內(nèi)存管理組件、文件系統(tǒng)組件將軟件模塊下載到文件系統(tǒng)，然后再通過(guò)動(dòng)態(tài)加載組件完成模塊的動(dòng)態(tài)加載及動(dòng)態(tài)鏈接。

3.2 動(dòng)態(tài)加載器

3.2.1 內(nèi)存布局規(guī)劃

嵌入式系統(tǒng)資源使用一般規(guī)劃的比較嚴(yán)格，尤其在內(nèi)存使用方面。DSP程序的開(kāi)發(fā)需要通過(guò)cmd文件的鏈接腳本預(yù)先規(guī)劃好內(nèi)存的整體布局。主機(jī)系統(tǒng)對(duì)動(dòng)態(tài)庫(kù)的加載主要是由進(jìn)程控制塊來(lái)維護(hù)整個(gè)32位虛擬地址空間的內(nèi)存使用，通過(guò)查詢(xún)空閑空間找到未使用區(qū)域后，再加載動(dòng)態(tài)庫(kù)。因?yàn)閯?dòng)態(tài)庫(kù)加載后隨著應(yīng)用生命周期一直運(yùn)行，不會(huì)像堆數(shù)據(jù)空間的內(nèi)容、大小經(jīng)常性變化。基于以上特點(diǎn)，采取在鏈接腳本中規(guī)劃出固定大小的內(nèi)存空間BLOB區(qū)域?qū)Ｓ糜趧?dòng)態(tài)庫(kù)加載。加載器會(huì)計(jì)算加載的模塊總共占用內(nèi)存空間的大小，當(dāng)預(yù)先規(guī)劃的加載空間不足時(shí)會(huì)通過(guò)Shell向用戶(hù)提示，需要用戶(hù)重新規(guī)劃內(nèi)存空間布局。

鏈接腳本如下：

3.2.2 加載的模塊管理

加載器的功能主要是完成動(dòng)態(tài)庫(kù)文件的加載，包括ELF文件頭解析，文件格式有效性判斷。對(duì)實(shí)際加載的模塊信息進(jìn)行維護(hù)，包括文件頭、程序頭、加載段等信息，為后續(xù)的模塊卸載、依賴(lài)性分析提供支撐。描述模塊描述信息的結(jié)構(gòu)體定義如圖5，并通過(guò)DLIMP_Loaded_Module*loaded_module指針建立已加載模塊的維護(hù)鏈表快速遍歷模塊的相關(guān)信息。

圖5 加載模塊的管理Fig.5 Load module management

3.2.3 加載的段管理

依據(jù)ELF文件格式定義，其包含了諸多段，但并不是所有段對(duì)模塊的實(shí)際運(yùn)行有作用。根據(jù)內(nèi)存訪問(wèn)模型和編譯器選項(xiàng)，在動(dòng)態(tài)加載過(guò)程中需要加載同實(shí)際運(yùn)行相關(guān).plt、.got、.data、.text段，詳見(jiàn)表4。

表4 加載段的作用Table 4 Functions of loading section

最終加載到實(shí)際運(yùn)行內(nèi)存空間的段視圖，如圖6。

圖6 模塊加載后的.BLOB塊內(nèi)存視圖Fig.6 BLOB Block memory view after module loading

3.3 動(dòng)態(tài)鏈接器

動(dòng)態(tài)鏈接器將dll模塊加載完成后，根據(jù)導(dǎo)入符號(hào)的名稱(chēng)遍歷查找已加載的Base映像的導(dǎo)出符號(hào)，將符號(hào)地址填入到.plt、.got段中，使已加載的模塊具備執(zhí)行能力，如圖7。

圖7 重定址過(guò)程Fig.7 Re addressing process

4 結(jié)語(yǔ)

本文通過(guò)分析在嵌入式系統(tǒng)中軟件模塊動(dòng)態(tài)加載的使用需求和動(dòng)態(tài)鏈接原理，并在天熠嵌入式操作系統(tǒng)的產(chǎn)品中實(shí)現(xiàn)了基于C6678處理器的軟件模塊動(dòng)態(tài)加載組件。該組件可以完成多個(gè)用戶(hù)定義模塊的自動(dòng)（文件系統(tǒng)）、手動(dòng)（網(wǎng)絡(luò)或串口終端）加載及卸載，可用于支持嵌入式系統(tǒng)的功能重構(gòu)、產(chǎn)品的動(dòng)態(tài)升級(jí)、故障恢復(fù)，最終使整個(gè)系統(tǒng)擴(kuò)展性和靈活性大大提高，較好地滿(mǎn)足了用戶(hù)的實(shí)際需要。