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

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

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

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

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

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

函數調用跟蹤的常見類型

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

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

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

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

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

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

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

圖1：ELF文件格式

二進制文件 （ELF） 分析

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

圖2：靜態函數分析的過程

解析引擎遍歷反匯編代碼，并通過帶有鏈接 （BL） 的分支和具有鏈接和交換 （BLX） 指令的分支檢查函數調用，查找每個函數的所有調用函數，并填充函數數據庫。數據庫本身被安排為一個阿德爾森-維爾斯基和蘭迪斯自平衡搜索樹，用于快速搜索和瀏覽。

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

功能瀏覽器

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

瀏覽器界面

函數列表顯示所有可用函數，使您能夠選擇感興趣的函數來瀏覽引用。

圖3：功能列表顯示

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

圖 4：調用的函數引用

圖 5：從引用調用

圖 6：函數列表 GUI

簡化軟件

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

審核編輯：郭婷