新型Linux開(kāi)發(fā)工具應對下一代嵌入式系統設計挑戰

為了充分利用 Linux 操作系統，原始設備制造商(OEM)可選擇與商用 Linux 供應商合作，或在內部增添工程能力。這兩種模式都已被證明是成功的，但是每種做法都需各自的成本。

不管 OEM 如何選擇，他們的工程師所使用的典型調試模型都是相同的：基于 GDB(GNU Debugger)的客戶(hù)服務(wù)器環(huán)境。如圖1所示，它描述了在調試目標時(shí)，附加并運行在每個(gè) Linux 進(jìn)程中的 GDBSERVER 例示。每個(gè) GDBSERVER 都通過(guò)一個(gè)以太網(wǎng)端口與主機通信。

另外，需要特別注意的是，采用這種調試方法，標準 Linux內核被替換成一種“靜態(tài)”版本。僅有少數例外，所有通過(guò) KGDB的目標調試通信都被限制在 RS232 串行鏈路。

圖1: 標準 Linux 調試模型。

這種方法給開(kāi)發(fā)人員帶來(lái)了另一個(gè)挑戰，即要使用 Linux內核的測試版(instrumented version)。雖然這是可接受的默認Linux調試環(huán)境，但這種方法有一些很明確的局限性。例如，采用多進(jìn)程組成的應用，需要多個(gè) GDBSERVER 運行于有限的目標存儲器上。這可能影響被調試目標的性能，在一些情況下目標性能可降低50%以上。

即使在所有的內核工具和通信通道均可用的最佳情形下，仍有一些區域的代碼在這個(gè)調試范例下難以到達。圖2中說(shuō)明的“問(wèn)題”區域給內核和應用程序開(kāi)發(fā)人員提出了更多挑戰。這些區域包括每個(gè)進(jìn)程下大量的線(xiàn)程，以及代碼獨立和數據位置獨立的內核可加載模塊。盡管對于熟練的開(kāi)發(fā)人員來(lái)說(shuō)，有可能利用現有技術(shù)合成一個(gè)環(huán)境，來(lái)滿(mǎn)足這些區域的調試需要，但是這種環(huán)境對用戶(hù)非常不友好，且在負載下無(wú)法擴展。

圖 2: “問(wèn)題”區域。

接下來(lái)我們看看在Linux 內核可加載模塊的例子中，模塊加載時(shí)間調用的初始化程序由哪些部分組成。目前的調試范例表明加載了這些模塊，然后利用調試器對其代碼和數據偏移進(jìn)行調整(手動(dòng)和自動(dòng))。但是，這時(shí)模塊的初始化代碼已經(jīng)執行了，無(wú)法在代碼所在區域對問(wèn)題進(jìn)行調試。另一個(gè)使用情形涉及共享庫，這經(jīng)常無(wú)法由 GDBSERVER 或其他類(lèi)似程序很好地處理。即使存在這些問(wèn)題，許多工程師仍在采用 printf(用戶(hù)空間)和 printk(內核空間)作為主要調試幫助。一些調試“工具”帶來(lái)新的軟件問(wèn)題或可能掩蓋現有的問(wèn)題。