新型Linux開發(fā)工具應對下一代嵌入式系統(tǒng)設計挑戰(zhàn)
為了充分利用 Linux 操作系統(tǒng),原始設備制造商(OEM)可選擇與商用 Linux 供應商合作,或在內(nèi)部增添工程能力。這兩種模式都已被證明是成功的,但是每種做法都需各自的成本。
本文引用地址:http://m.butianyuan.cn/article/152135.htm不管 OEM 如何選擇,他們的工程師所使用的典型調(diào)試模型都是相同的:基于 GDB(GNU Debugger)的客戶服務器環(huán)境。如圖1所示,它描述了在調(diào)試目標時,附加并運行在每個 Linux 進程中的 GDBSERVER 例示。每個 GDBSERVER 都通過一個以太網(wǎng)端口與主機通信。
另外,需要特別注意的是,采用這種調(diào)試方法,標準 Linux內(nèi)核被替換成一種“靜態(tài)”版本。僅有少數(shù)例外,所有通過 KGDB的目標調(diào)試通信都被限制在 RS232 串行鏈路。
圖1: 標準 Linux 調(diào)試模型。
這種方法給開發(fā)人員帶來了另一個挑戰(zhàn),即要使用 Linux內(nèi)核的測試版(instrumented version)。雖然這是可接受的默認Linux調(diào)試環(huán)境,但這種方法有一些很明確的局限性。例如,采用多進程組成的應用,需要多個 GDBSERVER 運行于有限的目標存儲器上。這可能影響被調(diào)試目標的性能,在一些情況下目標性能可降低50%以上。
即使在所有的內(nèi)核工具和通信通道均可用的最佳情形下,仍有一些區(qū)域的代碼在這個調(diào)試范例下難以到達。圖2中說明的“問題”區(qū)域給內(nèi)核和應用程序開發(fā)人員提出了更多挑戰(zhàn)。這些區(qū)域包括每個進程下大量的線程,以及代碼獨立和數(shù)據(jù)位置獨立的內(nèi)核可加載模塊。盡管對于熟練的開發(fā)人員來說,有可能利用現(xiàn)有技術合成一個環(huán)境,來滿足這些區(qū)域的調(diào)試需要,但是這種環(huán)境對用戶非常不友好,且在負載下無法擴展。
圖 2: “問題”區(qū)域。
接下來我們看看在Linux 內(nèi)核可加載模塊的例子中,模塊加載時間調(diào)用的初始化程序由哪些部分組成。目前的調(diào)試范例表明加載了這些模塊,然后利用調(diào)試器對其代碼和數(shù)據(jù)偏移進行調(diào)整(手動和自動)。但是,這時模塊的初始化代碼已經(jīng)執(zhí)行了,無法在代碼所在區(qū)域?qū)栴}進行調(diào)試。另一個使用情形涉及共享庫,這經(jīng)常無法由 GDBSERVER 或其他類似程序很好地處理。即使存在這些問題,許多工程師仍在采用 printf(用戶空間)和 printk(內(nèi)核空間)作為主要調(diào)試幫助。一些調(diào)試“工具”帶來新的軟件問題或可能掩蓋現(xiàn)有的問題。
linux操作系統(tǒng)文章專題:linux操作系統(tǒng)詳解(linux不再難懂)
評論