由于具有射頻連接和微控制器內核的低成本集成片上系統設備的進步，物聯網 （IoT） 設備呈指數級增長。

其中許多設備主要基于 Arm? Cortex?-M 架構。隨著硬件的進步，嵌入式軟件在跟上新的連接協議、協議棧和框架方面發揮著重要作用。

然而，連接設備的激增給嵌入式軟件工程師帶來了挑戰，尤其是同時在多個設備和框架上工作的應用和維護工程師。

學習新設備軟件、框架和協議棧的工作方式可能非常耗時，并且會限制工程師快速解決問題的能力。設計文檔和內嵌源代碼注釋會有所幫助，但它們可能不容易訪問，并且可能無法提供代碼工作原理的完整畫面。

在這些情況下，工程師依靠他們的獨創性、足智多謀和使用集成開發環境 （IDE） 瀏覽源代碼。雖然這有助于理解軟件代碼流，但這是一個耗時且乏味的過程，但有更好的方法。

在本文中，我將介紹一種使用現有工具鏈實用程序來生成軟件的靜態函數調用層次結構并更快更好地理解軟件流程的新穎方法。

常見的函數調用跟蹤類型

您可以使用函數調用跟蹤來了解代碼流或識別錯誤。比較成功和失敗場景之間的程序流程（通過函數調用跟蹤）可以幫助您快速識別有問題的代碼區域以進行進一步檢查。

函數調用跟蹤補充了基于 IDE 的源代碼瀏覽，以更好地了解整個軟件實現，并且可以分為兩種常見的類別：

運行時函數調用跟蹤。這是一個侵入性過程，需要檢測源代碼。像 GNU Compiler Collection 這樣的工具鏈提供了放置函數調用的工具，這需要重建代碼以重新生成新的二進制文件，但會導致額外的代碼大小和更長的執行時間。對于缺乏內存的資源受限物聯網設備，運行時函數調用跟蹤可能不是一個可行的選擇。另外，您無法保證插樁代碼的行為與未插樁代碼的行為相同。

靜態函數調用。對于基于只讀存儲器 （ROM） 的設備，檢測不是一個可行的選擇。盡管您可以簡單地使用 Eclipse 或 Source Insight 等 IDE 瀏覽源代碼以了解軟件實現，但這是一個乏味的過程。一些 IDE（通常是昂貴的商業版本）可以派生靜態函數調用圖。這些靜態函數調用瀏覽器通常范圍有限，如果源代碼中有條件編譯，則可能無法提供整個調用流程的準確畫面。

但是，可以從反映實際二進制代碼的二進制可執行和可鏈接格式 （ELF） 文件生成靜態調用流瀏覽器。

使用靜態呼叫流瀏覽器更快地修復軟件

讓我們使用設備的 ELF 二進制圖像來生成函數調用參考詳細信息。如圖 1 所示，其想法是獲取 ELF 二進制文件并將其傳遞給各種代碼生成工具，例如 TI 的目標文件顯示 （armofd） 和反匯編程序 （armdis），以生成函數列表和調用引用數據庫。生成數據庫后，在簡單的樹形瀏覽器中顯示調用層次結構和流程，以查看函數調用引用。這些靜態調用流程圖還可以通過將運行時 ROM 代碼消息日志覆蓋在靜態函數樹的頂部來幫助調試——這種組合將提供對運行時代碼流的洞察并幫助您隔離問題。

圖 1：ELF 文件格式

二進制文件 （ELF） 分析

ELF 文件包含程序頭、節頭以及代碼和數據節。工具鏈提供了各種工具來檢查和以可讀格式顯示 ELF 二進制文件內容。在 TI，我們使用 armofd 和 armdis 等實用程序名稱來獲取 Arm 反匯編中的功能詳細信息和完整的程序編碼。

圖2：靜態函數分析流程

解析引擎遍歷反匯編代碼并通過帶有鏈接的分支 （BL） 和帶有鏈接和交換的分支 （BLX） 指令檢查函數調用，找到每個函數的所有調用函數，并填充函數數據庫。數據庫本身排列為 Adelson-Velsky 和 Landis 自平衡搜索樹，用于快速搜索和瀏覽。

編譯器優化可能會通過直接分支到被調用函數來扭曲某些函數調用。這些函數沒有任何堆棧分配，因此解析引擎需要足夠智能以檢測這些編譯器優化。

功能瀏覽器

稱為 Java 框架 （JFrames） 的簡單圖形用戶界面 （GUI） 界面選擇感興趣的函數以進行函數調用瀏覽。選擇一個函數會顯示兩個框架，一個用于“被調用者/被調用函數”，另一個用于“調用自”函數。這些框架顯示了具有進一步節點擴展的分層樹結構，如圖 3、4、5 和 6 所示。

瀏覽器圖形用戶界面

函數列表顯示所有可用函數，使您能夠選擇感興趣的函數以瀏覽參考文獻。

圖 3：功能列表顯示

可以進一步向下導航樹以查看函數調用的可能性。

圖 4：被調用的函數引用

圖 5：從引用中調用

圖 6：功能列表 GUI

簡化軟件

通過使用這種方法從二進制圖像中導出靜態調用流程圖，您現在可以更好地了解軟件功能流程并補充您的源代碼瀏覽，從而更深入地了解軟件實現。最重要的是，這種方法可以加快流程并使故障排除軟件更簡單。

審核編輯：郭婷