嵌入式軟件設計中查找缺陷的幾個技巧

確保永不發生堆棧溢出的唯一途徑就是分析代碼，確定程序在各種可能情況下的最大堆棧用量，然后檢查是否分配了足夠的堆棧。測試不大可能觸發特定的瞬時輸入組合進而導致系統出現最壞情況。

　　堆棧深度分析的概念比較簡單：

　　1. 為每個獨立的線程建立一棵調用樹。

　　2. 確定調用樹中每個函數的堆棧用量。

　　3. 檢查每棵調用樹，確定從樹根到外部“樹葉”的哪條調用路徑需要使用的堆棧最多。

　　4. 將每個獨立線程調用樹的最大堆棧用量相加。

　　5. 確定每個中斷優先級內各中斷服務程序(ISR)的最大堆棧用量并計算其總和。但是，如果ISR本身沒有堆棧而使用被中斷線程的堆棧，則應將ISR使用的最大堆棧數加到各線程堆棧之上。

　　6. 對于每個優先級，加上中斷發生時用來保存處理器狀態的堆棧數。

　　7.如果使用RTOS，則加上RTOS自身內部用途需要的最大堆棧數(與應用代碼引發的系統調用不同，后者已包含在步驟2中)。

　　除此之外，還有兩個重要事項需要考慮。首先，僅僅從高級語言源代碼建立的調用樹很可能并不完善。大部分編譯器采用運行時庫(run-time library)來優化常用計算任務，如大值整數的乘除、浮點運算等，這些調用只在編譯器產生的匯編語言中才可見。運行時庫函數本身可能使用大量的堆棧空間，在分析時必須將它們包括進去。如果使用的是C++語言，則以下所有類型的函數(方法)也都必須包含到調用樹內：結構器、析構器、重載運算符、復制結構器和轉換函數。所有的函數指針也都必須進行解析，并且將它們調用的函數包含進分析之中。

　　第二，編譯器使用一個C庫來實現memcpy()、cos()和atof ()等標準函數，而這些例程的源代碼可能無法得到。如果能夠得到它們的源代碼，就有可能確定程序用到的每個庫調用在最壞情況下的堆棧使用數量。如果這些庫只包含在目標文件中，則編譯器廠商必須提供每個庫例程使用的堆棧數。如果沒有這些信息，就無法通過分析來確定最壞情況下程序使用的最大堆棧數。幸運的是，許多面向嵌入式系統的編譯器廠商都提供這些信息。

　　通常，每次一個函數被調用時，編譯器將使用堆棧來保存返回地址并傳遞函數參數。函數的自動(局部)變量通常也在堆棧當中。不過，由于編譯器會盡可能通過將參數或局部變量放入寄存器來優化代碼，因此檢查匯編語言以精確地確定堆棧用量非常重要。編譯器也有可能在代碼中的其它地方選擇使用堆棧，如用堆棧來保存中間計算結果。

　　有些與編譯器一起打包銷售的開發環境包含生成調用樹的工具，還有許多第三方的調用樹生成工具。但是，除非它們能夠對匯編語言進行分析，否則這些工具可能會遺漏運行時庫和C庫的調用。不過無論在哪種情況下，開發分析匯編語言文件并提取函數名稱以及各函數內部調用的腳本都比較簡單。分析的結果可寫入一個文件，而這個文件能夠方便地輸入到表格之中。

　　確定了各個函數的堆棧用量之后，必須計算每個線程所需的最大堆棧數。由于一般程序通常涉及數百個函數，調用跨越多層深度，處理這些信息的一種簡便方法就是采用分析表格。如表1所示，表格的各行包含了函數名稱、該函數使用的最大堆棧數(包括調用其它函數所需的堆棧數)，以及它調用的所有函數的清單。通過編程控制，這個表格從每個函數的根開始迭代循環，計算該函數及其調用的所有函數需要的堆棧。這些信息存放在堆棧路徑列中，這樣，采用每個線程根函數(如main)的堆棧路徑數據就可以方便地計算出需要的最大堆棧數了。這個過程包含了先前介紹的堆棧分析過程中的前四個步驟。