COFF文件分析提取器的實現(xiàn)及其應(yīng)用
摘 要:在基于TI DSP的嵌入式應(yīng)用系統(tǒng)中,升級文件提取方法的效率和易用性對于DSP升級來說特別重要,傳統(tǒng)的提取方法耗時且容易出錯,為此迫切需要一種快速且可靠的方法。由于DSP編譯器最終輸出的可執(zhí)行代碼是一種COFF格式的文件,具有結(jié)構(gòu)化、分層次的特點,可以剔除其中與最終下載代碼無關(guān)的大量冗余信息。為此提出一種基于可執(zhí)行文件本身結(jié)構(gòu)特點的方法,只提取出與下載相關(guān)的數(shù)據(jù)。實踐證明這種方法高效、可靠、靈活易用。此提取器摒棄傳統(tǒng)方法的缺陷,為DSP在研發(fā)生產(chǎn)中的快速自動升級提供了可靠保證。
關(guān)鍵詞:COFF;段;DSP;冗余信息
在基于DSP的嵌入式系統(tǒng)中,軟件更新通常需要借助仿真器將最新的可執(zhí)行程序下載到目標(biāo)板上,然后提取出可執(zhí)行二進(jìn)制程序并寫入非易失存儲器中?;蛘唠x線進(jìn)行二進(jìn)制文件的提取,然后再由DSP自己或主機(jī)芯片完成文件的燒結(jié)。在此,有必要簡單介紹一下TI DSP可執(zhí)行程序(目標(biāo)文件)的結(jié)構(gòu)。TI代碼產(chǎn)生工具CCS在經(jīng)過編譯、鏈接之后,產(chǎn)生的目標(biāo)文件是一種模塊化的文件格式——COFF格式。程序中的代碼和數(shù)據(jù)在COFF文件中是以段的形式組織。在此基礎(chǔ)上,再來討論上面兩種方法的弊端。前者只要程序有變化,就會造成新生成目標(biāo)文件各段的大小和運(yùn)行地址的變化,其系統(tǒng)引導(dǎo)程序也需要作相應(yīng)的改動。如果需要對大量的DSP系統(tǒng)進(jìn)行軟件更新或經(jīng)常需要軟件更新的情況下,這種方法的效率非常低下,缺乏靈活性。后者的通常做法是先用工具軟件hex6x先將編譯器生成的目標(biāo)文件轉(zhuǎn)換成多個TI格式的.hex文件,再逐一分析.hex文件,手工去掉其中的一些標(biāo)志信息,并根據(jù)需要對文件進(jìn)行必要的分割合并,最后調(diào)用TI提供的工具軟件hexbin將各個.hex文件轉(zhuǎn)換成二進(jìn)制文件,生成文件的數(shù)目隨應(yīng)用而變化。這種方法因為涉及到手工操作費時費力不說且很容易出錯。同樣也存在著靈活性差的弊端,遇到有大量增減以及配置文件有修改的時候就會導(dǎo)致生成文件數(shù)目的增減,需要修改DSP或主機(jī)boot程序以適應(yīng)這種改變。通過對目標(biāo)文件結(jié)構(gòu)的分析,可以直接提取可供下載的二進(jìn)制文件。
l 目標(biāo)文件結(jié)構(gòu)分析
DSP的源程序——C代碼或匯編代碼在編譯后生成的COFF文件包含多個段,默認(rèn)的情況下,COFF文件包含3個段:.text:通常包含可執(zhí)行代碼;.data:通常包含已初始化的數(shù)據(jù);.bss:通常為未初始化的數(shù)據(jù)保留空間。
當(dāng)然匯編器和鏈接器允許自己建立和鏈接自定義的塊,這些塊與以上的3個段類似。所有的段分為兩大類:已初始化段和未初始化段。這兩類段的最大區(qū)別就在于是否出現(xiàn)在加載文件中。
下面來分析COFF文件的結(jié)構(gòu),COFF文件從上到下中依次是文件頭、可選的文件頭、段頭信息表、段頭信息表對應(yīng)的段數(shù)據(jù)、重定位信息、行號入口表、符號表、字符串表,如圖1所示。其中第3~6項包含多個數(shù)據(jù)區(qū),前4項與加載文件密切相關(guān)。
由于前4項與加載文件相關(guān),下面對這4項逐一分析一下:
(1)文件頭:顧名思義,就是COFF文件的頭,用來保存COFF文件的基本信息,如段數(shù)目、時間戳、符號表位置等。從文件的0偏移處開始,用C的結(jié)構(gòu)描述如下:
[!--empirenews.page--]
文件頭中的標(biāo)記包含了諸如大小端模式、COFF是否為可執(zhí)行文件等信息,具體解釋見參考文獻(xiàn)。
(2)可選頭:可選頭接在文件頭的后面,也就是從COFF文件的Ox0014偏移處開始。長度可以為O。不同平臺的可選頭,長度和結(jié)構(gòu)都不相同,TI DSP采用的可選頭長度為28 B,用C的結(jié)構(gòu)描述如下:
(3)段頭:段頭緊跟在可選文件頭的后面(如果可選文件頭的長度為0,它緊跟在文件頭后),一般COFF包含多個段頭,數(shù)目就是文件頭中的usSection—Counter。它的長度為48 B,用C的結(jié)構(gòu)描述如下:
段頭可以說是最重要的頭,文件分析提取器的核心就是用它來描述它的。一個COFF文件可以不要其它的節(jié),但文件頭和段頭這兩節(jié)是必不可少的。有必要詳述一下它的成員:
cName用來保存段名,常用的段名有.text,.da—ta,.bss等。對于用戶自定義長度超過8 B的段名,則為指向符號表的指針。
uiVirtAddr是段數(shù)據(jù)載入或連接時的虛擬地址。對于可執(zhí)行文件,這個地址是相對于它的地址空間而言。當(dāng)可執(zhí)行文件被載入內(nèi)存時,這個地址就是段中數(shù)據(jù)的第一個字節(jié)的位置。大多數(shù)情況下與uiPhyAddr相同。
uiSecSize是段中數(shù)據(jù)的實際長度,在讀取段數(shù)據(jù)時就由它來確定要讀多少字節(jié)。
uiSecPointer是段數(shù)據(jù)在COFF文件中的偏移量,以絕對地址標(biāo)識。
uiRelPointer是該段重定位信息的絕對地址,它指向了重定位表的1個記錄。
uiLNOffset是該段行號表的絕對地址,它指向的是行號表中的1個記錄。
uiRelSize是重定位信息的記錄數(shù),從uiRelPointer指向的記錄開始,到第ulNumRel個記錄為止,都是該段的重定位信息。
uiLNSize和uiRelSize相似,不過它是行號信息的記錄數(shù)。
uiFlags是該段的屬性標(biāo)識,與下載相關(guān)的標(biāo)識如表1所示。[!--empirenews.page--]
其余定義請見參考文獻(xiàn)。
(4)段數(shù)據(jù):保存各個段的數(shù)據(jù),在目標(biāo)文件中這些數(shù)據(jù)都以原始數(shù)據(jù)(Raw Data)形式存在,只有需要下載的數(shù)據(jù)段才存在該區(qū)域。
2 COFF文件分析提取器的工作流程
首先讀入目標(biāo)文件,該文件擴(kuò)展名為out,以二進(jìn)制形式讀入。分析.out文件的文件頭以確定有多少個段,然后逐段分析段信息頭,根據(jù)段屬性標(biāo)識以確定是否需要下載,段頭中的絕對地址、段數(shù)據(jù)長度等信息作為升級文件的一部分。與需下載的段數(shù)據(jù)合并成最終的下載文件,為了適應(yīng)自動化升級的需要,下載文件頭部還保留了COFF文件的時戳。值得注意的是因為TMS320C6000 DSP為32位處理器,需要對段落頭中段數(shù)據(jù)長度信息進(jìn)行32位整型對齊,在此采用Ceil對齊——不足的字節(jié)以O(shè)補(bǔ)齊。具體流程如圖2所示。
而COFF文件中的重定位信息、行號入口表、符號表、字符串表等數(shù)據(jù)區(qū),對于下載文件的制作沒有直接聯(lián)系,可以不做分析。當(dāng)然,如果在PC上制作可視化工具的話,另當(dāng)別論,限于篇幅在此不做討論。
3 COFF文件分析提取器的應(yīng)用
開發(fā)的DSP應(yīng)用系統(tǒng)一般采用HOST—SLAVE模式,即DSP是作為系統(tǒng)的信號處理協(xié)處理單元,HOST保存有所有處理器的下載文件。COFF文件分析提取器在做離線使用時,提取出的下載文件由H0ST負(fù)責(zé)保存、上電加載。HOST的引導(dǎo)程序在上電時讀取已經(jīng)構(gòu)建好的二進(jìn)制文件,根據(jù)段數(shù)目、每段大小以及目標(biāo)數(shù)據(jù)的下載地址等相關(guān)信息即可完成對目標(biāo)代碼的自動下載。COFF文件分析提取器在線使用時,時間戳就作為版本是否更新的依據(jù),HOST一旦偵測到版本服務(wù)器有新版本的COFF文件并得到用戶升級確認(rèn)后,就可啟動文件提取器。
目前,這種利用COFF文件分析提取器生成DSP下載文件的方式,已經(jīng)在中興通訊多個產(chǎn)品線廣泛應(yīng)用,大大提高了產(chǎn)品的可測試性和易維護(hù)性。
4 結(jié) 語
在此討論的方法基于對COFF文件結(jié)構(gòu)的分析,讀取DSP編譯器生成的.out文件,根據(jù)文件本身攜帶的信息,直接提取生成可供下載的二進(jìn)制文件。最終生成的二進(jìn)制文件中包含有與.out文件相同的信息,在下載時利用這些信息即可完成對DSP芯片的加載。