單片機開發功能安全中的編譯器

2020-08-05

在各個領域，功能安全領域對開發人員提出了新要求。功能上安全的代碼必須包括防御性代碼，以防御各種原因引起的意外事件。例如，由于編碼錯誤或宇宙射線事件而導致的內存損壞可能導致執行根據代碼邏輯“不可能”的代碼路徑。高級語言，特別是C和C ++，包含數量眾多的功能，這些功能的行為不是代碼所遵循的語言規范所規定的。這種不確定的行為可能導致意外的結果和潛在的災難性后果，而這在功能安全的應用程序中是無法接受的。出于這些原因，標準要求應用防御性編碼，可測試的編碼，有可能整理足夠的編碼覆蓋率，

代碼還必須實現高級別的代碼覆蓋率，在某些領域（尤其是汽車領域），設計通常需要復雜的外部診斷，校準和開發工具。出現的問題是，防御性編碼和外部數據訪問等實踐并不屬于編譯器認可的領域。例如，C和C ++都沒有為內存損壞留出任何余地，因此，除非在沒有這種損壞的情況下可以訪問旨在防止內存損壞的代碼，否則在對代碼進行優化時可以將其忽略。因此，如果不“優化”防御性代碼，則必須在語法和語義上都可以實現。

未定義行為的實例也會引起意外。很容易建議應避免使用它們，但通常很難識別它們。如果存在它們，就不能保證已編譯的可執行代碼的行為將符合開發人員的意圖。對調試工具使用的數據的“后門”訪問代表了該語言不允許的另一種情況，因此可能會帶來意想不到的后果。

編譯器優化可能對所有這些領域產生重大影響，因為它們都不屬于編譯器供應商的職責范圍。優化可能會導致在與“不可行”相關聯時，即在存在于無法通過任何可能的輸入值進行測試和驗證的路徑上存在的情況下，顯然消除了防御性代碼。更令人震驚的是，在構建系統可執行文件時，很可能會消除在單元測試期間顯示的防御代碼。僅僅因為在單元測試期間已經實現了防御性代碼的覆蓋范圍，因此并不能保證其已存在于完整的系統中。

在功能安全這個陌生的領域，編譯器可能超出了其要素。這就是為什么目標代碼驗證（OCV）代表了對任何與故障相關的后果都有嚴重后果的系統的最佳實踐，甚至對于只有最佳實踐就足夠好的任何系統都代表了最佳實踐。

編譯前后

功能安全性，安全性和編碼標準（例如IEC 61508，ISO 26262，IEC 62304，MISRA C和C ++）提倡的驗證和確認做法非常強調顯示在基于需求的測試中使用了多少應用程序源代碼。

經驗向我們表明，如果已證明代碼可以正確執行，則現場失敗的可能性會大大降低。但是，由于這種值得稱贊的努力的重點是高級源代碼（無論使用哪種語言），所以這種方法使編譯器具有創建目標代碼的能力，這些目標代碼可以準確地再現開發人員的能力，這使人們深信不疑預期的。在最關鍵的應用程序中，該隱含假設無法成立。

不可避免的是，目標代碼的控制和數據流不會完全是源代碼的鏡像，因此證明所有源代碼路徑都可以可靠地行使并不能證明目標代碼是同一件事。 。鑒于目標代碼和匯編器之間存在1：1的關系，因此可以比較源代碼和匯編代碼?？紤]一下圖1所示的示例，其中右邊的匯編代碼是從左邊的源代碼生成的（使用禁用了優化的TI編譯器）。

圖1：右邊的匯編代碼是從左邊的源代碼生成的，顯示了源代碼和匯編代碼之間的明顯對比

如下所述，當編譯此源代碼時，生成的匯編代碼的流程圖與源代碼的流程圖完全不同，因為C或C ++編譯器遵循的規則允許它們以自己喜歡的任何方式修改代碼，前提是二進制表現為“好像是一樣的。”

在大多數情況下，該原則是完全可以接受的-但存在異常情況。編譯器優化基本上是數學上的變換，可應用于代碼的內部表示。如果假設不成立，這些轉換就會“出錯”-例如，在代碼庫包含未定義行為的實例的情況下，這種情況經常發生。

只有航空航天業中使用的DO-178C才將重點放在開發人員意圖與可執行行為之間潛在的危險不一致的可能性上，即使如此，仍不難找到具有明顯潛能的解決方法的倡導者，以免發現那些不一致之處。但是，可以原諒此類方法，但事實是，源代碼和目標代碼之間的差異可能在任何關鍵應用程序中造成毀滅性后果。

開發人員意圖與可執行行為

盡管源代碼流和目標代碼流之間存在明顯差異，但它們并不是主要問題。編譯器通常是高度可靠的應用程序，盡管可能會像其他任何軟件一樣存在錯誤，但編譯器的實現通常會滿足其設計要求。問題在于這些設計要求并不總是反映功能安全系統的需求。

簡而言之，可以假定編譯器在功能上符合其創建者的目標。但這可能并不完全是期望或期望的結果，如下面的圖2所示，其中包括一個使用CLANG編譯器進行編譯的示例。

圖2顯示了使用CLANG編譯器進行的編譯

顯然，在匯編代碼中并未表達對“錯誤”功能的防御性呼吁。

僅在初始化“ state”對象時以及在“ S0”和“ S1”情況下修改“ state”對象，因此編譯器可以推斷出賦予“ state”的唯一值是“ S0”和“ S1”。編譯器得出結論，不需要“默認值”，因為假設沒有損壞，“狀態”將永遠不包含任何其他值-實際上，編譯器所做的正是這一假設。

編譯器還決定，由于實際對象（13和23）的值未在數字上下文中使用，因此它將僅使用0和1的值在狀態之間切換，然后使用異或“或”更新狀態值。二進制文件遵循“好像”義務，并且代碼快速緊湊。在其職權范圍內，編譯器做得很好。

此行為對使用鏈接器內存映射文件間接訪問對象的“校準”工具以及通過調試器直接訪問內存有影響。同樣，這些考慮因素也不屬于編譯器的職責范圍，因此在優化和/或代碼生成期間不會考慮。

現在假設代碼保持不變，但是在呈現給編譯器的代碼中其上下文發生了微小的變化，如圖3所示。

圖3：代碼保持不變，但是提供給編譯器的代碼中的上下文略有變化

現在有一個附加函數，該函數以整數形式返回狀態變量的值。這次，絕對值13和23在提交給編譯器的代碼中很重要。即使這樣，這些值也不會在更新函數中進行操作（保持不變），并且僅在新的“ f”函數中可見。

簡而言之，編譯器繼續（正確地）對應該使用13和23的值進行價值判斷，并且絕不會將它們應用于可能的所有情況。

如果更改了新功能以返回指向我們狀態變量的指針，則匯編代碼將發生重大變化。由于現在存在通過指針進行別名訪問的可能性，因此編譯器無法再推斷出狀態對象正在發生的情況。如下圖4所示，它不能得出13和23的值不重要的結論，因此現在可以在匯編器中明確表示它們。

圖4：如果將新函數更改為返回指向我們的狀態變量的指針，則匯編代碼將發生重大變化。它不能得出結論13和23的值并不重要，因此它們現在已在匯編程序中明確表示

對源代碼單元測試的影響

現在，在虛構的單元測試工具的上下文中考慮示例。由于需要一種工具來訪問被測代碼，因此會操縱狀態變量的值，因此默認值不會“被優化”。這種方法在沒有與源代碼其余部分相關的上下文并且需要使所有內容都可訪問的測試工具中是完全合理的，但是，其副作用是，它可以掩蓋編譯器對防御性代碼的合法遺漏。

編譯器認識到已通過指針將任意值寫入狀態變量，并且不能再次得出13和23的值不重要的結論。因此，它們現在在匯編器中明確表示。在這種情況下，不能得出結論：S0和S1代表狀態變量的唯一可能值，這意味著默認路徑可能可行。如圖5所示，狀態變量的操作達到了目的，并且在匯編器中現在可以明顯看到對錯誤函數的調用。

圖5：狀態變量的操作已達到其目的，并且錯誤函數的調用現在在匯編程序中顯而易見

但是，這種操作不會出現在產品內隨附的代碼中，因此對error（）的調用實際上不在整個系統中。

目標代碼驗證的重要性

為了說明目標代碼驗證如何幫助解決這個難題，請再次考慮第一個示例代碼片段，如圖6所示：

圖6：這說明了目標代碼驗證如何幫助解決錯誤提示在整個系統中的作用

通過一次調用，可以證明此C代碼實現了100％的源代碼覆蓋率，因此：

f_while4（0,3）;

可以將代碼重新格式化為每行單個操作，并在流程圖上表示為“基本塊”節點的集合，每個節點都是一系列直線代碼?；緣K之間的關系在圖7中使用節點之間的有向邊表示。

圖7：使用節點之間的有向邊顯示基本塊之間的關系

編譯代碼后，結果如下所示（圖8）。流程圖的藍色元素表示調用f_while4（0,3）尚未執行的代碼。

通過利用目標代碼與匯編代碼之間的一對一關系，此機制可以揭示目標代碼的哪些部分未被執行，從而促使測試人員設計其他測試并實現完整的匯編代碼覆蓋范圍，從而實現目標代碼驗證。

圖8：顯示了編譯代碼后的結果。流程圖的藍色元素表示調用f_while4（0,3）尚未執行的代碼

顯然，目標代碼驗證無權阻止編譯器遵循其設計規則，并無意中繞開了開發人員的最佳意圖。但這確實可以并且確實會引起任何此類失配，引起粗心的人的注意。

現在，在前面的“錯誤提示”示例的上下文中考慮該原理。當然，完整系統中的源代碼將與在單元測試級別上證明的源代碼相同，因此，將其進行比較不會發現任何問題。但是，將目標代碼驗證應用于完整的系統對于確?；拘袨榘凑臻_發人員的意圖進行表達將具有極大的價值。