DSP編程技巧之5---揭開(kāi)編譯器神秘面紗之調試與路徑選項
發(fā)布時(shí)間：2014-9-4 16:51
發(fā)布者：
看門(mén)狗
作者：paradoxfx 來(lái)源：電子產(chǎn)品世界
在程序的編寫(xiě)與測試中，調試功能是非常重要的，很多時(shí)候我們需要一步步的調試與觀(guān)察才能找到一些隱藏很深的bug，所以要對編譯器的調試選項有一些了解，下面我們首先看一下編譯器的調試選項都有哪些。
表1 編譯器的調試選項
| 選項 | 別名 | 優(yōu)化的效果 | | --symdebug:dwarf | -g | -g是默認選項，在缺省情況下，大多數程序和庫都是帶調試符號（gcc 參數 -g）編譯的。當調試一個(gè)帶調試符號的程序時(shí)，調試器不僅能給出內存地址，還能給出函數和變量的名字。產(chǎn)生符號調試信息并不會(huì )影響程序的優(yōu)化效果。 | 注：DWARF是一種很復雜的二進(jìn)制文件格式，它和和 STAB 格式是使用最廣泛的兩種可執行和鏈接格式 (ELF)。DWARF（使用任意記錄格式調試）是面向 ELF 文件的一種較新的格式。創(chuàng )建該格式是為了彌補 STAB 中的一些缺陷，從而能夠提供更詳細、更簡(jiǎn)便的數據結構描述、變化的數據移動(dòng)和復雜的語(yǔ)言結構，比如 C 中的語(yǔ)言結構。調試信息存儲在對象文件的各個(gè)部分中。這種格式是可執行程序與源代碼之間關(guān)系的簡(jiǎn)單表示，為了便于調試器對該關(guān)系進(jìn)行處理。對此感興趣的網(wǎng)友可以搜索《The DWARF Debugging Standard》標準仔細閱讀，或者參考IBM的網(wǎng)頁(yè)說(shuō)明 http://www.ibm.com/developerworks/cn/opensource/os-debugging/。 | | --symdebug:coff | | 使用交替的STABS調試格式來(lái)使能符號調試；調試信息的傳統格式被稱(chēng)為 STAB（符號表）。STAB 調試格式是一種記錄不完整的半標準格式，用于調試 COFF 和 ELF 對象文件中的信息。調試信息是作為對象文件的符號表的一部分進(jìn)行存儲的，因此復雜性和范圍是有限的。 | 使用這種格式的目的是為了與一些很古老的調試器或者用戶(hù)自定義的調試工具進(jìn)行兼容，因為這些工具往往不兼容新的DWARF格式。 | 使用這個(gè)選項有可能會(huì )對程序的優(yōu)化造成影響，因為為了使用STAB格式下的調試功能，有些代碼需要被保留而無(wú)法優(yōu)化。 | | --symdebug:none | | 禁止所有的符號調試信息。 | 不建議使用這個(gè)選項，因為它禁用了調試功能，并使得程序的性能分析變得非常困難。比如說(shuō)我們測算代碼的運行時(shí)間的時(shí)候，就需要在代碼中插入斷點(diǎn)使用調試功能完成測算。 | | --symdebug:profile_coff | | 使用交替的STABS調試格式來(lái)進(jìn)行程序的性能分析。 | 在CCS里，使用這個(gè)選項可以在函數級別上插入斷點(diǎn)并估算程序運行時(shí)間，但是不能使用單步調試功能。 | | --symdebug:skeletal |
| 已經(jīng)廢棄的參數，不再建議使用，即使使能也不產(chǎn)生任何效果。 | | --optimize_with_debug | -mn | 已經(jīng)廢棄的參數，不再建議使用，即使使能也不產(chǎn)生任何效果。 | | --symdebug:keep_all_types |
| 這是一個(gè)編譯器的高級調試選項，它用來(lái)保持未參考的類(lèi)型信息。也就是說(shuō)，使能這個(gè)選項之后，可以在調試時(shí)觀(guān)察定義包含在COFF可執行文件中，但是沒(méi)有被任何地方引用的符號（默認情況下這樣的符號是不具有調試信息的，使能調試之后變可以進(jìn)行一些調試相關(guān)的工作了）。 |
調試選項看起來(lái)非常復雜，不過(guò)通過(guò)前面幾次的講解也可以看出，這些名字特別長(cháng)，并且一般情況下沒(méi)有別名(縮寫(xiě)名)的選項，基本都是輸入高級選項，對于一般使用者來(lái)說(shuō)的話(huà)，我們的主要目的不是去關(guān)心它編譯過(guò)程中有多么復雜的信息，只要利用它的結果，所以一個(gè)-g選項就能滿(mǎn)足大多數情況的使用了。
然后針對初學(xué)者經(jīng)常遇到的找不到頭文件或者宏定義的問(wèn)題，這個(gè)貌似是大多數初學(xué)者在新建工程時(shí)、添加完文件然后編譯程序時(shí)都會(huì )遇到的：明明看見(jiàn)頭文件它就在那里了，可是編譯器就是不認識它;或者在CCS里面已經(jīng)打開(kāi)了頭文件能看到內容了，可是編譯器一直在提示xxx.h頭文件打不開(kāi)。因為頭文件里定義了各種各樣的變量、結構體、宏定義甚至函數聲明等，所以一個(gè)頭文件找不到的話(huà)往往會(huì )帶來(lái)幾十個(gè)上百個(gè)“未定義”相關(guān)的錯誤。在此我們就看一下編譯器的包含選項，理解了它的使用方法，自然就不會(huì )再遇到類(lèi)似的問(wèn)題了。
表2 編譯器的包含選項
| 選項 | 別名 | 優(yōu)化的效果 | | --include_path=directory | -I | 用來(lái)定義引用頭文件時(shí)#include中文件的路徑。這個(gè)不難理解，基本上就是指代我們在程序中引用頭文件時(shí)制定的頭文件的路徑。初學(xué)者經(jīng)常遇到的問(wèn)題就是頭文件找不到，然后出現一大堆的調試錯誤，所以要掌握這個(gè)選項。 | Ø 在引用頭文件時(shí)，如果使用雙引號”xxx.h”進(jìn)行引用的話(huà)，則編譯器在編譯時(shí)按照下面的順序和路徑依次進(jìn)行尋找： | 1. 從任何引用了xxx.h的源程序所在的文件夾里進(jìn)行搜索。所以在編譯時(shí)如果提示缺失xxx.h文件，最快捷的方法就是找到這頭文件把它放在源程序所在的文件夾里（當然這樣不利于有條理地管理工程文件）。 | 2. 從-I參數中所制定的路徑里面搜索。 | 3. 從安裝CCS時(shí)生成的C2000_C_DIR環(huán)境變量指向的路徑里面搜索。 | Ø 在引用頭文件時(shí)，如果使用尖括號進(jìn)行引用的話(huà)，則編譯器在編譯時(shí)按照下面的順序和路徑依次進(jìn)行尋找： | 1. 從-I參數中所制定的路徑里面搜索。 | 2. 從安裝CCS時(shí)生成的C2000_C_DIR環(huán)境變量指向的路徑里面搜索。 | 觀(guān)察兩種頭文件引用方法的共同點(diǎn)，我們可以得出，除了系統自帶的頭文件，例如這樣的我們不需要管它之外，我們自己定義和使用的頭文件一定要使用-I參數把路徑定義好，就不會(huì )再有什么頭文件打不開(kāi)、不存在之類(lèi)的錯誤了。那如果頭文件有多個(gè)路徑進(jìn)行存儲怎么辦呢？只要多次使用-I參數就行了，例如： | -i"..\..\ DSP2833x_headers\include" -i"..\..\DSP2833x_common\include" | | --preinclude=filename |
| 在編譯開(kāi)始時(shí)指定源程序的文件名filename。這個(gè)選項主要用來(lái)建立標準的宏定義。這些文件名的搜索也按照-I定義的路徑來(lái)進(jìn)行，并按照制定的順序編譯。 |
|
