今天小編想要給大家帶來的是最近在調試一個項目時候發現的怪事，同樣的函數庫在使用不同的IDE時，得到的運行結果竟然是不一致的。相信眼尖的讀者朋友已經從標題中猜出一二了，正是因為庫中依賴了浮點計算庫所導致的問題。那么就請和小編一起，探究下詳細的來龍去脈吧！

項目背景

首先再詳細描述以下項目背景：我們使用了一個由GCC工具鏈構建的函數庫，編譯器選項為-mfloat-abi=hard，即在編譯時，使能了硬件浮點單元指令加速。但在我們將該庫與Keil項目鏈接后，發現結果不正確。當然，我們最先懷疑的當然是庫編譯的有問題啦。但是奇怪的事情發生了，我當我們使用GCC工具鏈鏈接編譯相同的工程，并運行后，得到了正確的結果。那么可以基本確定，庫應該是沒有問題的。那么問題出在哪呢？

問題分析

由于小編所拿到的庫并不包含調試信息，只能通過一些技術手段進行破解。通過反匯編庫代碼，我們發現庫依賴了一些浮點計算庫的C函數，如sqrtf、expf等，為了簡便，讓我們稱之為xxf函數，由于GCC并沒有提供其具體實現，因此需要由庫的使用者鏈接這些函數，而經過進一步的debug，我們發現這些函數導致了錯誤的結果，換句話說，這些函數的返回值是錯的。

問題調試

隨后，隨便找到一個Keil的測試工程，我們這里選擇一個Hello_World示例工程，將編譯出來的.o文件添加到工程中：

并在主程序中添加調用代碼：

編譯鏈接下載程序，并讓程序停在函數調用處：

單步進入calc_sqrt函數內部，到這里，我們可以發現對這些函數的調用順序是正確的。通過將參數傳遞給S0（對于float）如下所示，S0中寸的就是待計算的數據4.0f：

看起來好像沒有問題，再進一步現在讓我們檢查由Keil鏈接的sqrtf函數的匯編實現：

相信大家發現了奇怪的事情了，鏈接的sqrtf將S0中的值傳遞給S0，而此時R0的值其實為0，但正如之前所說，浮點值已經由庫的代碼傳遞給了S0。因此，由于S0中實際要計算的值被臨時替換了，就導致了一個錯誤的結果。

這里要強調一下，如果在Keil中直接調用sqrtf時候，或是使用keil編譯器所編譯出來的.o文件，Keil運行時庫會使用“__hardfp_sqrtf”作為sqrtf的混淆名稱：

而因為我們所使用庫來自GCC工具鏈，因此Keil并不會對其進行替換，而是會將C庫中叫做sqrtf的函數直接鏈接進去，而這個函數的默認實現，是使用R0作為參數傳遞的寄存器。這也就導致，實際要被計算的數丟失，最終導致結果計算錯誤。

那么怎么解決這個問題，讓keil不去鏈接這個奇怪的sqrtf呢，這就要用到Keil的一個小技巧了：

這樣一來，調用sqrtf函數的地方，就會編程對$Sub$$sqrtf的調用：

而結果也變為正確的結果2.0了：

當然，大家可能會想啊，那我開了gcc優化之后，是不是就可以自動展開sqrtf了呢？讓我們來看看：

代碼并沒有變化：

結論

小編想用這個例子和大家說明下，在涉及到跨工具鏈開發時，一定要注意浮點庫的使用或依賴問題，由于不同編譯器對于浮點運算的實現可能有些許不同，會導致意想不到的奇怪問題出現。最好的方案，還是根據不同的工具鏈都構建一個專屬的庫來使用。

END

更多恩智浦AI-IoT市場和產品信息，邀您同時關注“NXP客棧”微信公眾號

NXP客棧

恩智浦致力于打造安全的連接和基礎設施解決方案，為智慧生活保駕護航。

長按二維碼，關注我們

恩智浦MCU加油站

這是由恩智浦官方運營的公眾號，著重為您推薦恩智浦MCU的產品信息、開發技巧、教程文檔、培訓課程等內容。

長按二維碼，關注我們