DSP編程技巧之5---揭開編譯器神秘面紗之調試與路徑選項

發布時間：2014-9-4 16:51 發布者：看門狗

關鍵詞： DSP , 編譯器 , CCS , STAB

作者：paradoxfx 來源：電子產品世界

　　在程序的編寫與測試中，調試功能是非常重要的，很多時候我們需要一步步的調試與觀察才能找到一些隱藏很深的bug，所以要對編譯器的調試選項有一些了解，下面我們首先看一下編譯器的調試選項都有哪些。

　　表1 編譯器的調試選項

選項	別名	優化的效果
--symdebug:dwarf	-g	-g是默認選項，在缺省情況下，大多數程序和庫都是帶調試符號（gcc 參數 -g）編譯的。當調試一個帶調試符號的程序時，調試器不僅能給出內存地址，還能給出函數和變量的名字。產生符號調試信息并不會影響程序的優化效果。
--symdebug:dwarf	-g	注：DWARF是一種很復雜的二進制文件格式，它和和 STAB 格式是使用最廣泛的兩種可執行和鏈接格式 (ELF)。DWARF（使用任意記錄格式調試）是面向 ELF 文件的一種較新的格式。創建該格式是為了彌補 STAB 中的一些缺陷，從而能夠提供更詳細、更簡便的數據結構描述、變化的數據移動和復雜的語言結構，比如 C 中的語言結構。調試信息存儲在對象文件的各個部分中。這種格式是可執行程序與源代碼之間關系的簡單表示，為了便于調試器對該關系進行處理。對此感興趣的網友可以搜索《The DWARF Debugging Standard》標準仔細閱讀，或者參考IBM的網頁說明http://www.ibm.com/developerworks/cn/opensource/os-debugging/。
--symdebug:coff		使用交替的STABS調試格式來使能符號調試；調試信息的傳統格式被稱為 STAB（符號表）。STAB 調試格式是一種記錄不完整的半標準格式，用于調試 COFF 和 ELF 對象文件中的信息。調試信息是作為對象文件的符號表的一部分進行存儲的，因此復雜性和范圍是有限的。
		使用這種格式的目的是為了與一些很古老的調試器或者用戶自定義的調試工具進行兼容，因為這些工具往往不兼容新的DWARF格式。
		使用這個選項有可能會對程序的優化造成影響，因為為了使用STAB格式下的調試功能，有些代碼需要被保留而無法優化。
--symdebug:none		禁止所有的符號調試信息。
--symdebug:none		不建議使用這個選項，因為它禁用了調試功能，并使得程序的性能分析變得非常困難。比如說我們測算代碼的運行時間的時候，就需要在代碼中插入斷點使用調試功能完成測算。
--symdebug:profile_coff		使用交替的STABS調試格式來進行程序的性能分析。
--symdebug:profile_coff		在CCS里，使用這個選項可以在函數級別上插入斷點并估算程序運行時間，但是不能使用單步調試功能。
--symdebug:skeletal		已經廢棄的參數，不再建議使用，即使使能也不產生任何效果。
--optimize_with_debug	-mn	已經廢棄的參數，不再建議使用，即使使能也不產生任何效果。
--symdebug:keep_all_types		這是一個編譯器的高級調試選項，它用來保持未參考的類型信息。也就是說，使能這個選項之后，可以在調試時觀察定義包含在COFF可執行文件中，但是沒有被任何地方引用的符號（默認情況下這樣的符號是不具有調試信息的，使能調試之后變可以進行一些調試相關的工作了）。

　　調試選項看起來非常復雜，不過通過前面幾次的講解也可以看出，這些名字特別長，并且一般情況下沒有別名(縮寫名)的選項，基本都是輸入高級選項，對于一般使用者來說的話，我們的主要目的不是去關心它編譯過程中有多么復雜的信息，只要利用它的結果，所以一個-g選項就能滿足大多數情況的使用了。

　　然后針對初學者經常遇到的找不到頭文件或者宏定義的問題，這個貌似是大多數初學者在新建工程時、添加完文件然后編譯程序時都會遇到的：明明看見頭文件它就在那里了，可是編譯器就是不認識它;或者在CCS里面已經打開了頭文件能看到內容了，可是編譯器一直在提示xxx.h頭文件打不開。因為頭文件里定義了各種各樣的變量、結構體、宏定義甚至函數聲明等，所以一個頭文件找不到的話往往會帶來幾十個上百個“未定義”相關的錯誤。在此我們就看一下編譯器的包含選項，理解了它的使用方法，自然就不會再遇到類似的問題了。

　　表2 編譯器的包含選項

選項	別名	優化的效果
--include_path=directory	-I	用來定義引用頭文件時#include中文件的路徑。這個不難理解，基本上就是指代我們在程序中引用頭文件時制定的頭文件的路徑。初學者經常遇到的問題就是頭文件找不到，然后出現一大堆的調試錯誤，所以要掌握這個選項。
		Ø 在引用頭文件時，如果使用雙引號”xxx.h”進行引用的話，則編譯器在編譯時按照下面的順序和路徑依次進行尋找：
		1. 從任何引用了xxx.h的源程序所在的文件夾里進行搜索。所以在編譯時如果提示缺失xxx.h文件，最快捷的方法就是找到這頭文件把它放在源程序所在的文件夾里（當然這樣不利于有條理地管理工程文件）。
		2. 從-I參數中所制定的路徑里面搜索。
		3. 從安裝CCS時生成的C2000_C_DIR環境變量指向的路徑里面搜索。
		Ø 在引用頭文件時，如果使用尖括號進行引用的話，則編譯器在編譯時按照下面的順序和路徑依次進行尋找：
		1. 從-I參數中所制定的路徑里面搜索。
		2. 從安裝CCS時生成的C2000_C_DIR環境變量指向的路徑里面搜索。
		觀察兩種頭文件引用方法的共同點，我們可以得出，除了系統自帶的頭文件，例如這樣的我們不需要管它之外，我們自己定義和使用的頭文件一定要使用-I參數把路徑定義好，就不會再有什么頭文件打不開、不存在之類的錯誤了。那如果頭文件有多個路徑進行存儲怎么辦呢？只要多次使用-I參數就行了，例如：
		-i"..\..\DSP2833x_headers\include" -i"..\..\DSP2833x_common\include"
--preinclude=filename		在編譯開始時指定源程序的文件名filename。這個選項主要用來建立標準的宏定義。這些文件名的搜索也按照-I定義的路徑來進行，并按照制定的順序編譯。

本文地址：http://m.qingdxww.cn/thread-132575-1-1.html 【打印本頁】

本站部分文章為轉載或網友發布，目的在于傳遞和分享信息，并不代表本網贊同其觀點和對其真實性負責；文章版權歸原作者及原出處所有，如涉及作品內容、版權和其它問題，我們將根據著作權人的要求，第一時間更正或刪除。