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

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

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

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

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

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

函數調用跟蹤的常見類型

可以使用函數調用跟蹤來了解代碼流或識別 bug。比較成功和失敗方案之間的程序流（通過函數調用跟蹤）可以幫助您快速識別代碼中存在問題的區域，以便進一步檢查。

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

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

靜態函數調用。對于基于只讀存儲器 （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

簡化軟件

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

審核編輯：郭婷