新型Linux開發(fā)工具應對下一代嵌入式系統(tǒng)設計挑戰(zhàn)
為了充分利用 Linux 操作系統(tǒng),原始設備制造商(OEM)可選擇與商用 Linux 供應商合作,或在內部增添工程能力。這兩種模式都已被證明是成功的,但是每種做法都需各自的成本。
不管 OEM 如何選擇,他們的工程師所使用的典型調試模型都是相同的:基于 GDB(GNU Debugger)的客戶服務器環(huán)境。如圖1所示,它描述了在調試目標時,附加并運行在每個 Linux 進程中的 GDBSERVER 例示。每個 GDBSERVER 都通過一個以太網(wǎng)端口與主機通信。
另外,需要特別注意的是,采用這種調試方法,標準 Linux內核被替換成一種“靜態(tài)”版本。僅有少數(shù)例外,所有通過 KGDB的目標調試通信都被限制在 RS232 串行鏈路。
圖1: 標準 Linux 調試模型。
這種方法給開發(fā)人員帶來了另一個挑戰(zhàn),即要使用 Linux內核的測試版(instrumented version)。雖然這是可接受的默認Linux調試環(huán)境,但這種方法有一些很明確的局限性。例如,采用多進程組成的應用,需要多個 GDBSERVER 運行于有限的目標存儲器上。這可能影響被調試目標的性能,在一些情況下目標性能可降低50%以上。
即使在所有的內核工具和通信通道均可用的最佳情形下,仍有一些區(qū)域的代碼在這個調試范例下難以到達。圖2中說明的“問題”區(qū)域給內核和應用程序開發(fā)人員提出了更多挑戰(zhàn)。這些區(qū)域包括每個進程下大量的線程,以及代碼獨立和數(shù)據(jù)位置獨立的內核可加載模塊。盡管對于熟練的開發(fā)人員來說,有可能利用現(xiàn)有技術合成一個環(huán)境,來滿足這些區(qū)域的調試需要,但是這種環(huán)境對用戶非常不友好,且在負載下無法擴展。
圖 2: “問題”區(qū)域。
接下來我們看看在Linux 內核可加載模塊的例子中,模塊加載時間調用的初始化程序由哪些部分組成。目前的調試范例表明加載了這些模塊,然后利用調試器對其代碼和數(shù)據(jù)偏移進行調整(手動和自動)。但是,這時模塊的初始化代碼已經執(zhí)行了,無法在代碼所在區(qū)域對問題進行調試。另一個使用情形涉及共享庫,這經常無法由 GDBSERVER 或其他類似程序很好地處理。即使存在這些問題,許多工程師仍在采用 printf(用戶空間)和 printk(內核空間)作為主要調試幫助。一些調試“工具”帶來新的軟件問題或可能掩蓋現(xiàn)有的問題。
[!--empirenews.page--]Arriba Debugger全面解決嵌入式Linux調試問題
Arriba Debugger從一開始就計劃為調試嵌入式 Linux 提供全面方案。VMON2取代了GDBSERVER 和 KGDB,是一種運行于嵌入式 Linux 目標的、動態(tài)可加載、基于需求的調試代理。通過與主機上的 Arriba Debugger 通信,從用戶級線程到靜態(tài)內核,VMON2 可實現(xiàn) Linux 目標完全可視性。VMON2的存儲器占位面積很小,即使在加載時,它對運行系統(tǒng)的性能影響也幾乎無法覺察。VMON2 在目標上的空間小于 250KB,能通過單以太網(wǎng)連接到目標平臺進行端到端的調試。
圖3: Arriba 解決方案。
問題 1 – 可加載模塊
通過 Arriba Debugger,當某一特性的內核模塊加載到目標時,VMON2 可進行配置,并向主機發(fā)送信號。接到這個信號后,Arriba Debugger 會自動且正確地加載各自模塊的符號信息,并對模塊初始化功能的入口點進行位置控制。現(xiàn)在,用戶可以通過高速以太網(wǎng)連接對有問題的模塊進行充分調試控制。與傳統(tǒng)Linux內核和模塊的調試不同,VMON2不預先占用內核,這對于以多數(shù)據(jù)和媒體為中心的應用而言非常關鍵。
問題 2 – 多進程調試;父/子進程
在許多情況下,Linux 應用程序開發(fā)人員需要創(chuàng)建包括多進程的應用。這樣的進程最初始于應用初始化程序中的一個父進程。一個常見的挑戰(zhàn)是考慮設置子進程斷點、并最終在子進程創(chuàng)建并運行時,滿足這些斷點的需求。這聽起來也許很簡單,但對現(xiàn)有的嵌入式或非嵌入式 Linux 調試來說尚未獲得支持。作為一個變通辦法,開發(fā)人員經常在由一個最初設為“真”變量選通的無限循環(huán)子進程中,人工插入用于測試的代碼。這有助于將 GDBSERVER 這樣的調試工具連接到有問題的子進程,將選通變量值變?yōu)椤凹佟眮斫獬h(huán)并恢復調試。
問題 3 – 調試內核驅動程序、共享庫…甚至已發(fā)布的產品內核
根據(jù)應用的范圍和寬度,Linux 調試的“問題區(qū)域”范圍可能涉及很廣。Arriba Debugger 為將來可能發(fā)生的問題提供了一個徹底的解決方案。編程人員和現(xiàn)場應用工程師需要能診斷和修復那些出現(xiàn)在產品中,并已被部署到現(xiàn)場的缺陷。在這種情況下,目標平臺取決于嚴格限制的調試和通信接入。作為可加載模塊,VMON2 可進行配置來啟動已經部署的系統(tǒng),因此,它能夠以極少的入侵有效調試并診斷系統(tǒng)。
Navigator集成元件套件(ICS)
MIPS 科技新發(fā)布了 MIPS Navigator集成元件套件(ICS)。Arriba Linux Debugger作為 MIPS Navigator ICS 的一個插件程序現(xiàn)可直接從 MIPS 科技獲得。這種無縫集成是 MIPS 科技和 Viosoft 公司之間合作的結果。
MIPS Navigator ICS中是一個功能豐富的Eclipse CDT環(huán)境,是專為MIPS架構定制的。另外,MIPS Navigator ICS 還包含最新的基于GNU的MIPS工具鏈CodeSourcery SG++,以及全部開發(fā)代碼必需的預期功能。MIPS Navigator ICS還集成了對所有MIPS科技的處理器IP的支持,包括PDTrace和EJTAG探針技術。
此外,開發(fā)人員還可利用另一款新的分析工具Arriba Linux Event Analyzer(LEA),它也是MIPS Navigator ICS的一個插件程序。這款工具可捕捉發(fā)生在目標中的所有Linux事件,根據(jù)時間順序用圖表顯示事件。Arriba LEA收集并提供大量關于Linux系統(tǒng)的信息,包括進程和線程間的上下文切換、信號和共用運行時間。LEA的存儲器占位面積小,幾乎不影響CPU周期,因此對于自主開發(fā)和現(xiàn)場服務而言都是理想的性能分析和調試工具。
圖4: Linux Event Analyzer (LEA) ICS視圖。
圖4顯示了一個LEA屏幕顯示的例子。LEA可以檢測外部事件延遲、響應時間,甚至是運行中的系統(tǒng)所出現(xiàn)的每個事件負載。該信息也可通過“原始”格式顯示,易于導入Microsoft Excel進行其他后處理和分析。
終端用戶的應用各不相同,同一組織內的每個開發(fā)人員或團隊可能采用LEA系統(tǒng)的不同方面。這就需要開放端分析工具具有高度可定制的設計能力。通過創(chuàng)建和配置各自插入LEA的內核模塊,開發(fā)人員可輕易且迅速地對其應用和系統(tǒng)進行觀察。LEA采用與VMON2相同的測試技術(instrumentation technology),這意味著不需要調試補丁或對Linux內核進行專門編譯。
Arriba Linux Debugger、Arriba LEA 和 MIPS Navigator ICS 的組合為MIPS開發(fā)人員提供了一個全面而強大的Linux開發(fā)環(huán)境,有助于縮短客戶產品上市時間,同時使開發(fā)人員能夠實現(xiàn)優(yōu)秀的代碼質量。