陳 鑫

（航空工業(yè)西安航空計(jì)算技術(shù)研究所，陜西 西安 710068）

0 引言

隨著ARJ21、C919等多個(gè)民用飛機(jī)型號(hào)的相繼研制，通用航空領(lǐng)域的不斷發(fā)展，我國機(jī)載軟件研制過程中，越來越廣泛地認(rèn)可和使用代表國際先進(jìn)水平的、來自美國和歐洲等航空發(fā)達(dá)國家的 RTCA DO-178B[1]/C[2]適航標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)規(guī)定了軟件研制過程中的各項(xiàng)活動(dòng)和多個(gè)目標(biāo)，但沒有給出如何完成這些活動(dòng)，也沒有說明如何達(dá)到這些目標(biāo)。經(jīng)過技術(shù)人員的不斷努力，國內(nèi)已能應(yīng)對(duì)標(biāo)準(zhǔn)中的大部分要求，但對(duì)標(biāo)準(zhǔn)中提到的軟硬件集成過程輸出的驗(yàn)證、以及編譯鏈接過程和目標(biāo)碼等內(nèi)容，仍有不少困惑。

本文在簡述DO-178B/C標(biāo)準(zhǔn)對(duì)軟硬件集成過程輸出驗(yàn)證的要求的基礎(chǔ)上，指出了該活動(dòng)與目標(biāo)碼覆蓋分析（OCA）活動(dòng)的差別，并以GCC編譯器為例，結(jié)合國產(chǎn)機(jī)載嵌入式操作系統(tǒng)TM2，提出了一個(gè)軟硬件集成過程輸出驗(yàn)證的詳細(xì)解決方案。

1 適航要求

根據(jù)適航要求，機(jī)載軟件作為高安全高可靠軟件，軟件開發(fā)過程應(yīng)該確保源代碼被正確編譯和鏈接、沒有引入錯(cuò)誤[3]；從驗(yàn)證角度講，就是要對(duì)軟硬件集成過程的輸出進(jìn)行評(píng)審和分析。DO-178B/C的6.3.5節(jié)提出應(yīng)該檢查下列缺陷：

（1）編譯器告警[2]；

（2）硬件地址錯(cuò)誤[1,2]；

（3）軟件部件遺漏[1,2]；

（4）內(nèi)存重疊[1,2]；

考慮到目前軟件開發(fā)過程一般會(huì)采用集成開發(fā)環(huán)境（IDE），因此，驗(yàn)證人員應(yīng)該關(guān)注IDE提供的軟件編譯、鏈接和加載過程，要評(píng)審和分析編譯器、鏈接器和加載器等的參數(shù)和默認(rèn)配置。

2 與OCA活動(dòng)的差異

由于對(duì)軟硬件集成過程輸出的評(píng)審和分析活動(dòng)與OCA活動(dòng)都涉及目標(biāo)碼，導(dǎo)致兩者容易混淆，實(shí)際上兩者差異很大。

軟硬件集成過程輸出的評(píng)審和分析活動(dòng)的目標(biāo)是確保該過程是完整的和正確的；活動(dòng)針對(duì) A、B和C級(jí)軟件，關(guān)心編譯器、鏈接器和加載器等的使用情況；對(duì)目標(biāo)碼來說，該活動(dòng)考慮的是目標(biāo)碼文件中的各種符號(hào)（全局變量、函數(shù)等），并不考慮編譯過程中生成的無法追溯到源代碼的目標(biāo)碼；該活動(dòng)的具體細(xì)節(jié)在后文討論。

OCA活動(dòng)的目標(biāo)是確保編譯生成的目標(biāo)碼序列的正確性；當(dāng)軟件是 A級(jí)、軟件結(jié)構(gòu)覆蓋分析（SCA）在源代碼級(jí)進(jìn)行、且編譯過程生成了無法追溯到源代碼的目標(biāo)碼時(shí)，才需要進(jìn)行OCA；該活動(dòng)先識(shí)別出哪些目標(biāo)碼不能追溯到源代碼，然后再通過附加驗(yàn)證來確認(rèn)這些額外的目標(biāo)碼能夠正確地運(yùn)行、并且不會(huì)引入異常行為[4]。

下面先簡要介紹機(jī)載軟件開發(fā)常用的交叉編譯工具 GCC，再結(jié)合國產(chǎn)機(jī)載嵌入式操作系統(tǒng) TM2（它使用GCC 3.4.4工具鏈），詳細(xì)討論軟硬件集成過程輸出的評(píng)審和分析活動(dòng)的7個(gè)子活動(dòng)。

3 GCC 編譯鏈接的基本過程

GCC是一套面向嵌入式領(lǐng)域的交叉編譯工具，支持多種編程語言、多種優(yōu)化選項(xiàng)、多種調(diào)試信息格式、多種反匯編方式、以及分步編譯，支持X86、ARM7、StrongARM、PPC4XX、MPC8XX、MIPS R3000等多種CPU[5]。

GCC編譯程序的基本過程見圖1所示。首先，core-gcc根據(jù)輸入文件的后綴來確定文件的類型，然后根據(jù)用戶的編譯選項(xiàng)（包括優(yōu)化選項(xiàng)、調(diào)試信息選項(xiàng)等）將其編譯成相應(yīng)的匯編臨時(shí)文件（后綴為.s）；接著，dcore-as將該匯編文件編譯成目標(biāo)文件（后綴為.o）；最后，dcore-ld根據(jù)用戶的鏈接選項(xiàng)（包括指定鏈接命令文件等）將目標(biāo)文件和各種庫鏈接起來生成可執(zhí)行文件[5]。

圖1 GCC 編譯鏈接的基本過程Fig.1 Basic process of the GCC compilation and link

4 解決方案

4.1 驗(yàn)證思路

從圖1可以看出，在源代碼到可執(zhí)行碼的轉(zhuǎn)換過程中，交叉編譯和匯編、交叉鏈接等步驟均可能引入錯(cuò)誤[3]。但是，由于編譯鏈接工具本身的復(fù)雜性，目前對(duì)它的完全驗(yàn)證還存在非常困難的技術(shù)問題[6]；因此工程項(xiàng)目中通常不對(duì)編譯鏈接工具做正確性假設(shè)，而是通過檢查編譯鏈接活動(dòng)的輸入與輸出來確保該過程的完整性和正確性；對(duì)加載可執(zhí)行碼到目標(biāo)機(jī)這個(gè)步驟的驗(yàn)證思路也是如此。換句話說，對(duì)軟硬件集成過程輸出的驗(yàn)證可以通過評(píng)審和分析軟件編譯信息、代碼源文件、工程文件（MakeFile）、內(nèi)存配置文件、目標(biāo)文件、可執(zhí)行文件等來進(jìn)行。在這個(gè)活動(dòng)中，主要應(yīng)該檢查下列7類缺陷，其中，前4類對(duì)應(yīng)DO-178B/C適航標(biāo)準(zhǔn)，后3類是對(duì)前4類的補(bǔ)充，對(duì)后3類的要求大多來自于項(xiàng)目經(jīng)驗(yàn)。

4.2 編譯器告警

編譯器輸出的告警信息代表軟件源代碼在編譯過程中出現(xiàn)了故障[3]。檢查告警信息分下面兩步。

第一步：設(shè)置編譯器選項(xiàng)，輸出所有告警信息，方法是：在 TM2開發(fā)環(huán)境中，選擇“產(chǎn)生所有警告信息（-Wall）”；

第二步：重新構(gòu)建 OS項(xiàng)目，人工分析所有構(gòu)建輸出信息，確認(rèn)編譯過程中不存在編譯錯(cuò)誤和告警信息；如果有告警信息，開發(fā)方應(yīng)提供解釋，驗(yàn)證方需判斷解釋是否合理；最好由開發(fā)方修改源代碼以消除告警信息。

4.3 硬件地址錯(cuò)誤

開發(fā)方提供硬件設(shè)備地址，驗(yàn)證方檢查源代碼中的硬件地址是否與開發(fā)方提供的一致；不一致的，開發(fā)方需要改成一致。

4.4 軟件部件遺漏

軟件部件的評(píng)審和分析用于確認(rèn)各個(gè)源文件（*.c、*.h）不多不少的被編譯成目標(biāo)文件（*.o），又不多不少地被鏈接到可執(zhí)行文件（*.elf、*.bin）中，主要檢查下列內(nèi)容：

（1）正確的源文件是否被包含在工程文件（MakeFile）中；

（2）源代碼文件之間的依賴關(guān)系是否正確；

（3）所有源文件是否都生成目標(biāo)文件；

（4）所有目標(biāo)文件是否都連接到可執(zhí)行文件中。

第1項(xiàng)檢查方法：根據(jù)開發(fā)方提供的源文件列表，在 TM2開發(fā)環(huán)境中查看工程文件（例如：makefile、source.mk、v_makefile.mk等），檢查源文件是否已經(jīng)不多不少地包含在這些工程文件中。

第2項(xiàng)檢查方法：在TM2開發(fā)環(huán)境的make/src目錄中，查看subdir.mk文件，該文件中有進(jìn)行編譯的每個(gè)源文件對(duì)應(yīng)的目錄文件（*.d）和目標(biāo)文件（*.o）的列表；根據(jù) subdir.mk文件，依次查看每個(gè).d文件，一個(gè).d文件中列出了某個(gè)源文件編譯時(shí)編譯器使用的所有依賴文件；根據(jù)這個(gè)依賴文件列表，結(jié)合開發(fā)方提供的文件調(diào)用關(guān)系樹和源文件中的#include語句，檢查該源文件的依賴關(guān)系是否正確。

需要說明的是：

· *.d文件中的依賴文件列表有前后順序，這是由C語言本身的要求決定的；

· 編譯器自己使用的頭文件，在源文件中會(huì)用#include語句列出，但在*.d文件中不會(huì)列出；

· 根據(jù)開發(fā)方提供的文件調(diào)用關(guān)系樹，可以在代碼審查時(shí)先檢查一下文件依賴關(guān)系是否正確；

· 檢查依賴關(guān)系時(shí)，依次查看源文件中的每個(gè)#include語句，并查看每個(gè)被包含文件內(nèi)再次包含的文件，以此類推，類似于深度優(yōu)先算法，這樣就可以從源文件中的各個(gè)#include語句得到該源文件的完整的依賴文件列表；把這個(gè)列表和開發(fā)方提供的文件調(diào)用關(guān)系樹、以及*.d文件中的依賴文件列表進(jìn)行比較，三者應(yīng)該一致。

第3項(xiàng)檢查方法：根據(jù)開發(fā)方提供的源文件列表，檢查源文件與目標(biāo)文件是否一一對(duì)應(yīng)。

第4項(xiàng)檢查方法：在TM2開發(fā)環(huán)境中，查看工程文件 makefile，查找以“dcore-ld”開頭的鏈接器命令。一個(gè)鏈接器命令后面包括有鏈接了的*.o文件，多個(gè)鏈接器命令之間沒有直接關(guān)聯(lián)，鏈接器工作時(shí)順序執(zhí)行這些命令。檢查所有鏈接器命令，列出命令后面包括的所有*.o文件，這些*.o文件與第3項(xiàng)得到的目標(biāo)文件列表應(yīng)該一致。

4.5 內(nèi)存重疊

4.5.1 段間重疊檢查

檢查開發(fā)方提供的內(nèi)存分配表和編譯器實(shí)際需要的各段的大小，要求分配的內(nèi)存應(yīng)大于或等于實(shí)際需要的內(nèi)存，以此驗(yàn)證內(nèi)存各個(gè)段之間是否重疊。

在 TM2開發(fā)環(huán)境中，查看配置項(xiàng)目下的configRecord.xml文件，里面有為項(xiàng)目“.text”、“.rodata”、“.data”和“.bss”等段分配的內(nèi)存空間的大小，這個(gè)分配應(yīng)該和開發(fā)方提供的內(nèi)存分配表一致；項(xiàng)目目錄下的catlinkcmds文件里面是編譯器實(shí)際需要的各段的大??；檢查這兩個(gè)文件中各段的空間大小，驗(yàn)證各段之間是否重疊。

4.5.2 段內(nèi)重疊檢查

可執(zhí)行文件中的地址，即鏈接后產(chǎn)生的地址，是加載到目標(biāo)機(jī)的地址（絕對(duì)地址）。驗(yàn)證方通過反匯編的方法，列出可執(zhí)行文件中各個(gè)符號(hào)（全局變量、函數(shù)等）的地址，檢查一個(gè)段內(nèi)各個(gè)符號(hào)的地址之間是否重疊。

TM2開發(fā)環(huán)境在鏈接后可以生成兩種可執(zhí)行文件：*.elf和*.bin。*.elf可以解析成文本文件，*.bin則只能是二進(jìn)制文件；兩者只是格式差異，內(nèi)容是一致的。驗(yàn)證方可以從*.elf中抽出每個(gè)符號(hào)的一些信息，命令是：dcore-nm -s os.elf > osMap.txt；該命令從 os.elf文件中抽出數(shù)據(jù)并存到 osMap.txt文件中，其中的信息包括：符號(hào)名、類型、占用空間的大?。╯ize）、起始地址、符號(hào)所在文件和行號(hào)等，見圖2所示。驗(yàn)證方檢查這些數(shù)據(jù)，判斷一個(gè)段內(nèi)各個(gè)符號(hào)的地址之間是否重疊。

需要說明的是：在TM2開發(fā)環(huán)境make目錄下的map.txt文件（內(nèi)存映像文件）中有更多有關(guān)符號(hào)的信息。

4.6 內(nèi)存動(dòng)態(tài)分配失控

驗(yàn)證方檢查源代碼中是否存在內(nèi)存動(dòng)態(tài)分配（例如malloc()語句）。如果沒有內(nèi)存動(dòng)態(tài)分配，內(nèi)存重疊的可能性較小；如果有內(nèi)存動(dòng)態(tài)分配，應(yīng)檢查是否對(duì)動(dòng)態(tài)分配空間的大小進(jìn)行了約束，或者釋放了前面分配的內(nèi)存空間（例如 free()語句）；如果即沒有約束，也沒有釋放，則可能在軟件運(yùn)行過程中出現(xiàn)內(nèi)存重疊，這是不安全的。

需要說明的是：本項(xiàng)活動(dòng)可以在代碼審查時(shí)進(jìn)行。

4.7 編譯鏈接選項(xiàng)錯(cuò)誤

開發(fā)方應(yīng)該明確本項(xiàng)目的編譯鏈接選項(xiàng)，驗(yàn)證方檢查開發(fā)環(huán)境中的編譯鏈接選項(xiàng)與開發(fā)方提供的是否一致；不一致的，開發(fā)方需要改成一致。

需要說明的是：

· 本項(xiàng)活動(dòng)可以作為對(duì)軟硬件集成過程輸出的評(píng)審和分析活動(dòng)的第一項(xiàng)子活動(dòng)；

· 目前，還沒有針對(duì)某一個(gè)編譯器鏈接器各個(gè)選項(xiàng)在特定情況下是否適用的規(guī)范性或指導(dǎo)性文件，因此，這一步主要依據(jù)是開發(fā)方提供的編譯鏈接選項(xiàng)，只要開發(fā)環(huán)境中的編譯鏈接選項(xiàng)與其一致即可。

4.8 加載過程錯(cuò)誤

加載過程檢查可用于確認(rèn)可執(zhí)行文件被正確地加載到目標(biāo)機(jī)中的正確位置，主要檢查下列內(nèi)容：

（1）加載器對(duì)加載的數(shù)據(jù)是否進(jìn)行了有效性檢查（例如CRC校驗(yàn)）；

（2）可執(zhí)行文件是否被加載到目標(biāo)機(jī)的正確位置；

（3）無效的軟件是否沒有被加載到目標(biāo)機(jī)；

（4）數(shù)據(jù)加載過程是否沒有出現(xiàn)錯(cuò)誤；

（5）數(shù)據(jù)加載后軟件是否正常運(yùn)行；

（6）加載的軟件版本是否正確。

第1項(xiàng)檢查方法：驗(yàn)證方了解加載過程，再判斷是否有安全保證。TM2開發(fā)環(huán)境的加載過程是把可執(zhí)行文件分解成若干包，然后與目標(biāo)機(jī)上的常駐代理軟件通信，一包一包地傳到目標(biāo)機(jī)上的特定地址；在此過程中，使用CRC校驗(yàn)保證通信正確。

需要說明的是：對(duì)于其他加載器，需要開發(fā)方或加載器提供方先說明加載器如何加載，以及加載時(shí)如何進(jìn)行有效性檢查，驗(yàn)證方再進(jìn)行分析檢查。

第2項(xiàng)檢查方法：重新加載一次可執(zhí)行文件，檢查可執(zhí)行文件的加載起始地址是否與開發(fā)方給出的起始地址一致。

第3項(xiàng)檢查方法：在重新加載過程中，檢查加載了的可執(zhí)行文件是否與開發(fā)方給出的需要加載的文件一致。

第4項(xiàng)檢查方法：在重新加載過程中，檢查數(shù)據(jù)加載過程是否正常結(jié)束，沒有出現(xiàn)錯(cuò)誤。

第5項(xiàng)檢查方法：加載完畢后，啟動(dòng)目標(biāo)機(jī)，檢查軟件是否正常啟動(dòng)和運(yùn)行。TM2加載到目標(biāo)機(jī)、目標(biāo)機(jī)啟動(dòng)后，能夠傳回版本信息和知識(shí)產(chǎn)權(quán)信息，并在宿主機(jī)端完整顯示出來，就可以認(rèn)為軟件已經(jīng)正常啟動(dòng)和運(yùn)行。

需要說明的是，本項(xiàng)活動(dòng)不需要運(yùn)行測試用例，只要目標(biāo)機(jī)上的軟件能夠正常啟動(dòng)，進(jìn)入初始狀態(tài)即可。

第6項(xiàng)檢查方法：啟動(dòng)目標(biāo)機(jī)，檢查軟件顯示的版本信息是否與開發(fā)方提供的被測件版本信息一致。

如果上述6項(xiàng)檢查均通過，表明軟件可執(zhí)行碼加載到目標(biāo)機(jī)過程是正確的；如果有某項(xiàng)檢查沒有通過，驗(yàn)證方應(yīng)會(huì)同開發(fā)方再次驗(yàn)證。

4.9 小結(jié)

表1把上面7個(gè)子活動(dòng)中開發(fā)方和驗(yàn)證方的工作進(jìn)行了小結(jié)。

表1 開發(fā)方需要提供的信息和驗(yàn)證方檢查的缺陷對(duì)應(yīng)表Tab.1 Information afforded by developer anddefects checked by verifier

5 結(jié)束語

在機(jī)載嵌入式設(shè)備開發(fā)過程中，為了滿足 DO-178B/C適航標(biāo)準(zhǔn)提出的、驗(yàn)證軟硬件集成過程輸出的要求，本文詳細(xì)討論了對(duì)編譯器告警、硬件地址錯(cuò)誤、軟件部件遺漏、內(nèi)存重疊、內(nèi)存動(dòng)態(tài)分配失控、編譯鏈接選項(xiàng)錯(cuò)誤、加載過程錯(cuò)誤等7類缺陷的檢查方法和注意事項(xiàng)。文中提到了國產(chǎn)機(jī)載嵌入式操作系統(tǒng)TM2，只是為了說明方便；實(shí)際上，只要使用了GCC交叉編譯工具，不同項(xiàng)目在編譯器、鏈接器和加載器的使用方面差別不大，均可參考本文討論的方法進(jìn)行軟硬件集成過程輸出的驗(yàn)證活動(dòng)。

[1] RTCA/DO-178B Software Considerations in Airborne Systems and Equipment Certification[S]. 1992.

[2] RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification[S]. 2011.

[3] 宮偉祥, 趙婳. 民用機(jī)載軟件集成過程的技術(shù)研究[J]. 計(jì)算機(jī)系統(tǒng)應(yīng)用, 2016, 25(7).

[4] 童岳威, 劉建方. 民用飛機(jī)A級(jí)別機(jī)載軟件項(xiàng)目源代碼到目標(biāo)碼追溯性分析研究[J]. 科技視界, 2016, 20.

[5] GNU工具用戶手冊[Z].

[6] 任建國. 適航認(rèn)證中的目標(biāo)碼覆蓋率分析工具VerOCode[J].航空制造技術(shù), 2012, 22.