一款自主可控調試器軟件架構設計

林廣棟 黃光紅 趙紀堂 郭利鋒 耿 銳

(安徽芯紀元科技有限公司 安徽 合肥 230088)

0 引 言

計算機軟件誕生之初,調試器就是軟件開發人員的重要工具。最初的調試器是基于硬件直接實現的,通過硬件設備提供計算機底層的信息。直到計算機基礎軟件(如操作系統、編譯器)發展成熟到一定程度之后,用戶友好的開源或商業化調試軟件才出現。調試器的工作原理是基于處理器的硬件機制,或基于操作系統封裝后的異常處理機制,結合編譯器生成的調試信息,將軟件的狀態以方便的方式提供給軟件開發人員,并支持軟件開發人員對正在調試的軟件的狀態進行修改。調試器的基本功能包括控制軟件運行、查看軟件運行時的信息、修改軟件執行流程或狀態等。先進的調試器還會添加事件分析、向后運行等功能。時至今時,應用于計算機各領域的調試系統仍然在不斷發展中,各種新技術層出不窮[1-9]。近年來的創新點主要集中在針對新型架構處理器的調試技術[3]、針對區塊鏈軟件的調試技術[5]、針對虛擬仿真環境的調試技術[6]、智能調試技術[8]等。

目前,最常見開源調試器是GNU維護的GDB[10-12]。GDB是起源于Linux環境的調試器,既可以調試本機上運行的Linux進程,也可以調試遠端的嵌入式處理器。GDB定義了基于字符串的RSP(Remote Serial Protocol)通信協議與嵌入式調試硬件(如在線仿真器ICE:In-Circuit Emulator)進行通信。基于RSP和ICE,GDB可以對嵌入式處理器進行調試操作,如查看/修改寄存器、查看/修改內存、暫停/運行處理器等等。結合GNU的另一個工具GDBServer,還可以調試遠端Linux系統上運行的進程。GDB是開源軟件,已經被很多處理器廠商移植用于嵌入式處理器的調試,是目前使用最廣泛的調試工具[13-16]。但GDB對由數百片芯片組合而成的處理器陣列的調試功能支持不夠完善。

LLVM基金會維護的LLDB是近年來新開發的調試器軟件[17]。由于它和著名的開源編譯器LLVM一起維護,也值得引起關注。LLDB的目標是解決多線程調試、C++模板、重載等問題。它采用與GDB完全不同的軟件架構,其命令接口也與GDB不兼容。LLDB已經可以在macOS系統上成熟地使用。但LLDB的應用范圍目前還比較窄,其在Linux系統上雖然可以使用,但仍然在改進。LLDB目前還不支持調試Windows上的程序。

另外,還有一些比較小眾的商業調試器,如德國的勞特巴赫(LAUTERBACH)公司開發的TRACE32工具[18]。TRACE32是一款比較高端的調試器,價格非常昂貴。TRACE32開發工具擁有非常強大的功能,包括基本調試配置、RTOS、多核系統、虛擬目標調試、能耗分析以及強大的腳本語言等功能,可以支持市場中使用的80多種常見的微處理器架構。在TRACE32的界面中,用戶可以使用菜單、鼠標完成調試操作,也可以使用命令行操作。命令行操作可以完成菜單鼠標可以實現的所有功能,而且具有更大的靈活性。TRACE32的命令接口與GDB也是不兼容的。

美國的Green Hills公司是業界領先的嵌入式軟件平臺和開發環境供應商,專注于研發嵌入式編譯器、調試器、操作系統、開發環境[19]。該公司推出的TimeMachine調試套件是業界首個為開發人員在程序運行的時間維度上提供向前和向后完全可視性的調試器。該調試器可以在程序出錯時讓程序按時間順序向后連續或單步運行,從而快速準確地找出發生錯誤的地方。該調試器還可以采集操作系統內核服務調用等操作系統事件的跟蹤數據。該調試器提供的PathAnalyzer工具可以顯示程序調用棧的歷史變化記錄。

TRACE32和TimeMachine都是商業收費軟件,應用范圍并不廣泛。目前,應用最廣泛、研究最集中的還是開源調試器軟件GDB。本文將以GDB為參考,介紹一款自主可控的調試器軟件。

本文介紹了一款新穎的調試器軟件架構。該調試器軟件沒有在開源調試器軟件的基礎上進行改造,而是完全正向開發。其核心模塊調試信息解析模塊更是完全自主開發的。相比開源調試器軟件,該調試器軟件具有代碼量少、對多核/多芯片/多板卡調試的支持更完備的特點。

1 簡 介

“魂芯”系列DSP是由中國電子科技集團公司第三十八研究所自主研發的高性能多核DSP。“魂芯”系列DSP配套有完備的基礎軟件,包括編譯器、匯編工具鏈、調試器、操作系統、集成開發環境等。“魂芯”配套的調試器軟件稱為MCCD(Multi Core Code Debugger)[20-24]。MCCD從2012年開始開發,其命令行接口基于GDB的MI接口改造而來,目前也支持與GDB基本兼容的簡寫命令集。與GDB相比,MCCD具有如下特點:

GDB的8.3版的代碼庫有4 850個文件,兩百多萬行代碼。而MCCD目前只有111個文件,5萬余行代碼。MCCD目前基本滿足可視化開化環境的調試需求,且支持C/C++高級語言調試。MCCD雖然沒有GDB功能豐富,但是完全夠用。由代碼量可以看出,MCCD是一個非常簡潔的調試器軟件。

根據“魂芯”的硬件架構和軟件環境進行深度定制化開發。針對“魂芯”的硬件架構和軟件環境,MCCD在如下幾個方面進行了定制化的開發:多核調試、反匯編、芯片寄存器/內存段定義、C語言系統調用(輸入輸出、文件操作等)、板級配置、字/字節調試信息轉換等。這些功能經過多年的測試,已經成熟。

支持處理器集群調試。GDB對處理器集群調試的支持比較薄弱。GDB使用inferior的概念來管理一個被調試的進程,當需要調試多個進程時,要通過add-inferior命令添加inferior。GDB的調試命令只能發給一個inferior。如果要調試其他進程,需要通過inferior infno命令來設置infno號inferior為當前調試進程。此后GDB收到的調試命令都是針對該進程。當通過RSP協議調試嵌入式系統時,一個嵌入式設備相當于一個被調試的進程。可見,GDB同時只能對一個RSP協議管理的遠程調試鏈接進行調試。而MCCD經過定制化開發,已經可以支持對處理器集群的調試。通過解析調試命令后把底層調試通信包分發給不同的調試終端,MCCD支持一條調試命令同時對不同嵌入式設備上的多個處理器執行多核調試操作。

GDB相比MCCD,命令行接口更為豐富,且支持對Python、FORTRAN等語言的調試。但是短期內沒有在DSP上調試除C/C++語言以外的程序的需求。因此,MCCD的調試功能目前來看是足夠滿足“魂芯”DSP調試需求的。

GDB是由GNU開源組織維護的開源調試器軟件,是Linux系列下以及大多數嵌入式芯片調試的首選工具。GDB一直被持續維護和更新,目前已經更新到8.3.1版。GDB既支持對本機運行的程序進行調試,也支持通過RSP協議對遠程運行的程序進行調試。大多數嵌入式芯片的開發環境都通過移植GDB來支持調試。常見的做法是新增一個協議轉換軟件,該軟件一方面通過RSP協議與GDB進行通信,一方面通過私有協議與嵌入式調試硬件進行通信。MCCD與GDB在調試功能上的對比結果見表1。可以看出,相對于GDB,MCCD在處理器集群調試方面具有一些獨特的優勢。

2 設 計

2.1 架構介紹

MCCD內部的整體架構如圖1所示。MCCD以命令行接口的形式提供給用戶或集成開發環境使用。MCCDMI負責接收用戶輸入并打印MCCD輸出。無論MCCD調試多少個芯片,其命令行接口只有一個。因此,MCCDMI模塊只有一個實例。MCCDDebugger負責管理一個調試終端控制的多個芯片。調試終端代表一個與MCCD進行通信,并被MCCD調試的實體,可以是一個在線仿真器,也可以是一個芯片內部的具有調試功能的MCU。一個調試終端與MCCD之間通過一個TCP/IP協議進行通信。MCCD每多管理一個調試終端,就多實例化一個MCCDDebugger。隨著MCCD管理的調試終端的增多,MCCDDebugger的實例也隨之增多。

圖1 MCCD內部運行時軟件實例架構圖

每個MCCDDebugger實例負責具體的各種調試功能,其內部架構如圖2所示。

圖2 MCCDDebugger內部架構圖

各模塊的功能簡介如表2所示。

表2 MCCD內部各主要模塊簡介

續表2

2.2 功能實現流程

下面以查看變量為例展示上述各模塊之間互相配合完成調試動作的整體流程。按存儲位置劃分,變量分為局部變量和全局變量兩類。局部變量的位置需要分析當前活動的函數棧,找到用戶當前選擇的調試函數幀,結合調試信息中存儲的局部變量偏移位置,得到局部變量的地址。全局變量的地址可以直接通過調試信息獲取。按復雜程度劃分,變量又可以分為簡單變量和復雜變量。普通的int、long long、float、double型變量為簡單變量,得到其地址后通過讀內存就可以獲取其值。struct、數組、指針類型的變量為復雜變量,得到這些變量的地址后,還需要通過更復雜的解析方法,得到其內部的struct元素、數組元素或指針指向的地址。若用戶要查看的是復雜變量內部包含的更深層次的元素,則需要逐層解析,直到找到用戶指定的內部元素的地址。圖3展示了一般的查看變量調試功能實現流程。受篇幅限制,圖中沒有展示查看復雜變量的具體流程,查看復雜變量的過程可參考文獻[12]。圖中各序號按遞增的順序代表完成查看變量調試動作需要執行的步驟。各步驟簡述如下:

(1) 用戶或IDE(集成開發環境)發送查看變量命令。

(2) 根據調試命令中指定的核號或當前默認調試核號,找到管理該調試對象的MCCDDebugger類實例。

(3) 通過ThreadManager模塊,得到當前活動棧的當前調試幀的位置。

(4) 通過DebugInfo模塊,結合當前調試幀的位置,得到用戶要查看的變量(或變量內部的元素)的地址。

(5) 向MemoryManage模塊發送讀取內存請求,此時的內存地址為軟件看到的32位地址。

(6) 判斷該地址是否屬于芯片外部地址,如DDR上的地址。若屬于,進行相應的地址轉換。

(7) 判斷該地址是否屬于芯片內部的地址,如片上SRAM的地址。若屬于,根據多核處理器的核內地址和全局地址的轉換規則,進行相應的轉換。

(8) 向TargetDebug模塊發送讀內存請求。此時內存地址為硬件實現上的最終物理地址。

(9) TargetDebug向嵌入式系統上的調試終端發送查看內存命令,獲取該地址上的值。

(10) TargetDebug返回指定硬件地址上的值給MemoryManage。

(11) MemoryManage返回軟件地址上的內存值。

(12) MCCDebugger返回用戶指定的變量的值、類型。

(13) MCCDMI根據變量的值、類型等信息,將變量值轉換為字符串,輸出查看變量命令的返回結果。

圖3 查看變量調試功能實現流程

2.3 功能模塊接口設計

依賴倒置原則(Dependence Inversion Principle)是面向對象編程的六大基本原則之一。該原則要求程序盡量信賴于抽象接口,而不是具體實現。該原則可以通俗地表達為“對接口編程,而不是對實現編程”。基于該原則,可以使軟件模塊之間的依賴關系限定到模塊的接口,與模塊的具體實現解耦,使軟件易于擴展、修改。MCCD各子模塊的設計都遵守這一原則。每個功能模塊,首先設計獨立的接口,MCCDDebugger只調用這些基類定義的接口。接口是一個抽象基類,該類中只定義純虛函數,不定義成員變量和實體函數。這些純虛函數代表一個模塊對外提供的接口。每個模塊的功能實現在該基類的子類中。若該模塊在不同的情況下有不同的實現,則定義不同的子類,每個子類獨立地實現相同的基類接口。MCCDDebugger根據實際運行時的情況,決定實例化哪個子類。MCCDDebugger中,始終維護一個基類的指針,并調用基類提供的接口。根據虛函數的性質,實際運行時,MCCDDebugger中的函數調用會自動轉化為對具體子類實現的調用。

IRemoteComm是TargetDebug內部使用的與硬件仿真器或芯片模擬器通信模塊接口。如圖4所示,IRemoteComm是一個包含純虛函數的基類,它有兩個子類UDPRemoteComm和TCPRemoteComm。這兩個子類中會定義實現具體通信功能的函數。在某些硬件仿真器中,由于片上SRAM的限制,不能使用TCP協議,只能使用UDP協議。因此,MCCD既支持TCP通信,又支持UDP通信。UDPRemoteComm負責實現UDP調試通信協議,TCPRemoteComm負責實現TCP調試通信協議。MCCDDebugger在開啟一個調試會話時,根據用戶的選擇來決定實例化UDPRemoteComm還是TCPRemoteComm。MCCDDebugger中的實現代碼,只調用IRemoteComm中定義的函數接口,具體運行過程中,會自動調用其子類中的函數。

圖4 通信基類與子類關系

某些模塊的所有子類有一些共同的實現,或需要相同的成員變量。這些相同的成員變量和實現可以再集中到一個類中。具體的不同實現再定義為這個類的子類。如圖5所示,IDisAssemble定義了反匯編類的接口。所有反匯編類的實現都有一些共同的操作,如根據機器碼中的值格式化字符串、獲取機器碼中的若干位等。這些相同的操作若分別在各子類中實現,則代碼會非常冗余。因此,定義類CDisAssemble,該類實現了這些共同操作。針對具體不同芯片的反匯編類再繼承自此子類。DisAssemble100、DisAssemble1042、DisAssemble1041分別是針對不同芯片類型的反匯編子類。這些子類只需要實現該芯片的指令集中的不同操作碼即可。

DisAssemblePred代表對一種帶有謂詞控制功能的指令集的反匯編功能。該類中定義了對機器碼中的謂詞進行反匯編的常用操作。所有帶有謂詞控制功能的芯片的反匯編類都繼承自DisAssemblePred。HXDSP1041芯片的指令集帶有謂詞控制功能,因此其反匯編類DisAssemble1041繼承自DisAssemblePred。

圖5 反匯編基類與子類關系

2.4 設計模式

設計模式是伽馬等[25]基于軟件開發工業中常見的優秀設計方法總結提煉出的軟件設計一般方法。軟件按照設計模式總結的方法進行設計,會易于維護、擴展。設計模式為軟件從業人員提供了一套易于交流的概念和方法。目前公認的設計模式有23條。MCCD使用C++語言實現,為簡化軟件架構、方便代碼維護,大量使用設計模式。

1) 單件模式。單件模式確保一個類在整個程序中只有一個實例,且這個實例在整個程序中是共享的。無論調試的對象有多少個,MCCD都只有一個命令行接口。MCCD中使用MCCDMI類來解析調試命令,MCCDMI類只需要實例化一次。MCCD中使用單件模式實例化MCCDMI類。

2) 工廠方法。工廠方法定義類的一種方法,由該方法根據當程序的具體情況決定實例化哪個類。工廠方法返回一個該類的抽象接口。根據芯片類型的不同,各種調試動作的實現方法也不同,MCCDDebugger應根據不同的芯片類型分別實例化不同的調試功能類。每個調試功能類都有一個對應的工廠方法,該工廠方法的參數是芯片類型,返回該調試功能子類的抽象接口。該工廠方法內部,根據不同的芯片類型,實例化該調試功能基類的不同子類,并返回實例化的子類的指針。根據不同的芯片類型,該工廠方法“制造”出不同的功能子類,但在MCCDDebugger內部仍然以抽象接口的方式使用這些功能子類。這些抽象接口以虛函數的方式定義,會在運行時調用實例化的子類的具體的實現。

3) 狀態模式。狀態模式使一個對象的內部狀態改變時改變其行為。當判斷當前對象所處狀態的表達式太過繁瑣時,可以把對象的行為轉移到代表不同狀態的子類中。調試終端可能處于不同的狀態下,如未連接狀態、已連接狀態,調試芯片已選擇狀態等。每種狀態下,同樣的調試操作有不同的表現,需要以不同的方式實現。若簡單地讓每種調試操作根據所處的狀態作不同的處理,則各調試操作函數內部將會有類似的對調試對象狀態對進判斷的語句。如果以這種方式實現,不同狀態下的調試功能實現代碼將耦合在同一個類的各個方法中,難以維護和擴展。MCCD使用狀態模式,定義一個實現各種調試操作的抽象接口基類MCCDDebugState。該接口基類是一個純虛類,只定義抽象接口。再定義該接口基類在各種狀態下的具體實現子類,如DisconnectedMCCDDebugger、UnselectedMCCDDebugger、SelectedMCCDDebugger等。每個子類僅僅代表一種狀態下該調試操作的具體實現形式。MCCDDebugger把調試操作代理給調試操作的狀態子類,由該子類完成具體調試操作。當調試對象的狀態發生變化時,只需要把狀態基類的指針替換為新狀態子類的指針即可。通過這種方式,把不同狀態下調試操作的具體實現方式分離開來,便于代碼擴展與維護。

2.5 配置文件

MCCD一個可執行文件可以支持調試HXDSP100、HXDSP1042、HXDSP1041、HXDSP2441等多種芯片。每種芯片的寄存器數量、名稱、地址不同,內存段數量、大小、地址也不同。如果將這些信息固定在代碼中,將會導致代碼與芯片配置綁定,不利于代碼維護,不利于運行時查錯。MCCD使用兩種XML文件描述與功能無關的信息:芯片配置XML文件、板級配置XML文件。芯片配置XML文件描述芯片內部的、僅僅與芯片相關的信息,如寄存器名稱、讀寫屬性、地址等。而板級配置XML文件描述芯片外部的、與不同板卡相關的信息,如FLASH類型、大小、DDR配置信息等。通過這種方式,將調試功能實現流程用代碼實現,而與具體芯片、板卡相關的信息用XML文件描述。這樣,MCCD軟件的代碼中不會出現具體的寄存器地址、FLASH大小等信息,易于代碼維護。在MCCD使用過程中,根據需要選擇配置不同的XML文件或修改XML文件的內容,以適應不同的芯片或板卡,方便了MCCD軟件發行之后的維護。

1) 芯片配置文件。芯片描述XML文件描述芯片內部的信息,主要包括如下內容:(1) 片上SRAM的名稱、地址、大小;(2) 流水線各級的名稱、流水線程序地址、流水線指令寄存器地址;(3) 寄存器名稱、讀寫屬性、地址等。

圖6為一個芯片描述XML文件中部分內容的示例圖。這段XML文件的內容描述了4個寄存器的相關信息。其他片上寄存器的信息也以類似的方式描述。

圖6 芯片描述XML文件部分內容示例

每次MCCD開啟一次調試會話前,首先加載芯片描述XML文件,解析其中的內容,把相關的信息存儲到RegisterManager、MemoryManager、PipelineManager等類的實例中。之后的調試功能實現時,到這些類的實例處獲取這些信息即可。

2) 板級配置文件。MCCD調試器不但要支持對芯片內部資源的調試操作,還要支持對板卡上資源的調試操作。這些操作包括:燒寫/擦除片外Flash、讀/寫DDR等。若板卡上包含多個HXDSP芯片,MCCD要支持對所有HXDSP芯片的多核調試。而片外資源對每種板卡都是不同的,且和芯片類型并沒有直接關系。因此,設計板級配置描述XML文件,用來描述板卡上的資源信息。

該XML文件描述的信息包括:(1) 板上芯片的數量、每個芯片的ID等;(2) 片外Flash的種類,如SPI、并口,I2C ROM等;(3) Flash信息,包括頁大小、扇區大小、塊大小等;(4) DDR的物理地址、大小、配置信息等。

板級描述XML文件遵守多核聯盟(MCA:Multicore Association)定義的SHIM軟硬件接口標準[26-27]。多核聯盟是由多家商業公司和學術機構組成的國際組織,致力于硬件描述文件、運行時API接口等軟硬件接口的標準化。SHIM標準的目標是為日益多樣化的多核、多處理器、多板卡硬件資源定義一種統一的描述標準,以方便上層軟件以統一的方式使用不同的硬件資源。板卡描述XML文件主要定義板卡上的互聯關系,互聯關系信息中指定連接的器件的XML文件名稱。每個器件有一個單獨的XML文件來描述,如果一個器件被多個板卡使用,則只需要一份描述該器件信息的XML文件即可。圖7是板級互聯關系XML文件的片斷示例。該示例中定義了兩個DDR連接關系、一個并口Flash設備連接關系。DDR設備連接關系記錄了DDR顆粒的XML描述文件名稱,以及連接到芯片上的哪個DDR接口。Flash設備連接關系記錄了Flash的XML描述文件以及連接到的芯片并行接口。該文件中還會記錄DSP芯片的個數、種類以及芯片描述XML文件的名稱。

2.6 擴展性

硬件架構以及板卡配置相關信息在配置文件中描述。MCCD根據這些配置文件實現與硬件有關的調試操作。MCCD的主體代碼只與調試功能實現流程、調試信息管理、硬件配置信息管理有關。若要擴展到其他架構的處理器,只需要修改硬件配置文件,并對MCCD的代碼進行局部修改即可。具體需要修改的模塊包括:通信協議管理模塊、反匯編模塊、芯片配置信息管理模塊。根據不同芯片對調試時內核運行控制的方式不同,可能還需要對“運行控制模塊”進行適配和改造。對這些模塊的修改都不需要修改原有代碼,只需要在這些模塊的接口基類的基礎上繼承產生一個新子類即可。

3 結 語

本文描述了一款自主可控調試器軟件的架構設計方案,并比較了該調試器軟件與開源調試器軟件GDB相比的特點。該調試器軟件已經成功應用于“魂芯”各型號DSP,并支持基于可視化開發環境的調試功能。該調試器軟件相比GDB,命令行接口不夠豐富,但在集群調試等功能點上也有自己的特色。該調試器軟件的代碼量少,架構靈活,可以同時調試多種不同架構的芯片。通過修改芯片配置XML文件、板級配置XML文件,并對少數模塊進行移植,該調試器軟件可以很容易地移植到其他硬件架構的處理器。該調試器軟件的架構設計值得國內自主可控調試器軟件開發設計人員借鑒參考。