-pipe 的作用：

使用管道代替編譯中臨時文件， -pipe 加速編譯 gcc -pipe foo.c -o foo 加速 在將源代碼變成可執行文件的過程中,需要經過許多中間步驟,包含預處理、編譯、匯編和連接。這些過程實際上是由不同的程序負責完成的。大多數情況下 GCC 可以為 Linux 程序員完成所有的后臺工作,自動調用相應程序進行處理。這樣做有一個很明顯的缺點,就是 GCC 在處理每一個源文件時,最終都需要生成好幾個臨時文件才能完成相應的工作,從而無形中導致處理速度變慢。例如,GCC 在處理一個 源文件時,可能需要一個臨時文件來保存預處理的輸出、一個臨時文件來保存編譯器的輸出、 一個臨時文件來保存匯編器的輸出,而讀寫這些臨時文件顯然需要耗費一定的時間。 當軟件項目變得非常龐大的時候,花費在這上面的代價可能會變得很沉重。 解決的辦法是,使用 Linux 提供的一種更加高效的通信方式—管道。它可以用來同時連接兩個程序,其中一個程序的輸出將被直接作為另一個程序的輸入,這樣就可以避免 使用臨時文件,但編譯時卻需要消耗更多的內存。 在編譯過程中使用管道是由 GCC 的-pipe 選項決定的。下面的這條命令就是借助 GCC 的管道功能來提高編譯速度的：

# gcc -pipe foo.c -o foo

在編譯小型工程時使用管道,編譯時間上的差異可能還不是很明顯,但在源代碼非常多的大型工程中,差異將變得非常明顯。

-pedantic 的作用

當 GCC 在編譯不符合 ANSI/ISO C 語言標準的源代碼時,如果加上了-pedantic 選項,那么使用了擴展語法的地方將產生相應的警告信息：

# gcc -pedantic illcode.c -o illcode 、

illcode.c: In function `main': illcode.c:9: ISO C89 does not support `long long' illcode.c:8: return type of `main' is not `int'

需要注意的是,-pedantic 編譯選項并不能保證被編譯程序與 ANSI/ISO C 標準的完全兼容,它僅僅只能用來幫助 Linux 程序員離這個目標越來越近。或者換句話 說,-pedantic 選項能夠幫助程序員發現一些不符合 ANSI/ISO C 標準的代碼,但不是全部,事實上只有 ANSI/ISO C 語言標準中要求進行編譯器診斷的那些情況,才有可能被 GCC 發現并提出警告。 除了-pedantic 之外,GCC 還有一些其它編譯選項也能夠產生有用的警告信息。這些選項大多以-W 開頭,其中最有價值的當數-Wall 了,使用它能夠使 GCC 產生盡可能多的警告信息：

# gcc -Wall illcode.c -o illcode

?

illcode.c:8: warning: return type of `main' is not `int' illcode.c: In function `main': illcode.c:9: warning: unused variable `var'

GCC 給出的警告信息雖然從嚴格意義上說不能算作是錯誤,但卻很可能成為錯誤的棲身之所。一個優秀的 Linux 程序員應該盡量避免產生警告信息,使自己的代碼始終保持簡潔、優美和健壯的特性。

-Werror的作用

在處理警告方面,另一個常用的編譯選項是-Werror,它要求 GCC 將所有的警告當成錯誤進行處理,這在使用自動編譯工具 （如 Make 等） 時非常有用。 如果編譯時帶上-Werror 選項,那么 GCC 會在所有產生警告的地方停止編譯,迫使程序員對自己的代碼進行修改。只有當相應的警告信息消除時,才可能將編譯過程繼續朝前推進。執行情況如下：

# gcc -Wall -Werror illcode.c -o illcode

cc1: warnings being treated as errors

illcode.c:8: warning: return type of `main' is not `int' illcode.c: In function `main': illcode.c:9: warning: unused variable `var'

對 Linux 程序員來講,GCC 給出的警告信息是很有價值的,它們不僅可以幫助程序員寫出更加健壯的程序,而且還是跟蹤和調試程序的有力工具。建議在用 GCC 編譯源代碼 時始終帶上-Wall 選項,并把它逐漸培養成為一種習慣,這對找出常見的隱式編程錯誤很有幫助。

?

庫依賴

在 Linux 下開發軟件時,完全不使用第三方函數庫的情況是比較少見的,通常來講都需要借助一個或多個函數庫的支持才能夠完成相應的功能。從程序員的角度看,函數庫實際上就是一些頭文件（.h）和庫文件（.so 或者.a）的集合。雖然 Linux 下的大多數函數都默認將頭文件放到/usr/include/目錄下,而庫文件則放到/usr/lib/目錄下,但并 不是所有的情況都是這樣。正因如此,GCC 在編譯時必須有自己的辦法來查找所需要的頭文件和庫文件。 GCC 采用搜索目錄的辦法來查找所需要的文件,-I 選項可以向 GCC 的頭文件搜索路徑中添加新的目錄。例如,如果在/home/xiaowp/include/目錄下有編譯時所需要的頭文件,為了讓 GCC 能夠順利地找到它們,就可以使用-I 選項：

# gcc foo.c -I /home/xiaowp/include -o foo

同樣,如果使用了不在標準位置的庫文件,那么可以通過-L 選項向 GCC 的庫文件搜索路徑中添加新的目錄。例如,如果在/home/xiaowp/lib/目錄下有鏈接時所需要的庫文 件 libfoo.so,為了讓 GCC 能夠順利地找到它,可以使用下面的命令：

# gcc foo.c -L /home/xiaowp/lib -lfoo -o foo

值得好好解釋一下的是-l 選項,它指示 GCC 去連接庫文件 libfoo.so。Linux 下的庫文件在命名時有一個約定,那就是應該以 lib 三個字母開頭,由于所有的庫文件都遵循 了同樣的規范,因此在用-l 選項指定鏈接的庫文件名時可以省去 lib 三個字母,也就是說 GCC 在對-lfoo 進行處理時,會自動去鏈接名為 libfoo.so 的文件。

Linux 下的庫文件分為兩大類分別是動態鏈接庫（通常以.so 結尾）和靜態鏈接庫（通常以.a 結尾）,兩者的差別僅在程序執行時所需的代碼是在運行時動態加載的,還是 在編譯時靜態加載的。默認情況下,GCC 在鏈接時優先使用動態鏈接庫,只有當動態鏈接庫不存在時才考慮使用靜態鏈接庫,如果需要的話可以在編譯時加上-static 選項,強制 使用靜態鏈接庫。例如,如果在/home/xiaowp/lib/目錄下有鏈接時所需要的庫文件 libfoo.so 和 libfoo.a,為了讓 GCC 在鏈接時只用到靜態鏈接庫,可以使用下面的命令：

# gcc foo.c -L /home/xiaowp/lib -static -lfoo -o foo

代碼優化

代碼優化指的是編譯器通過分析源代碼,找出其中尚未達到最優的部分,然后對其重新進行組合,目的是改善程序的執行性能。 GCC 提供的代碼優化功能非常強大,它通過編 譯選項-On 來控制優化代碼的生成,其中 n 是一個代表優化級別的整數。 對于不同版本的 GCC 來講,n 的取值范圍及其對應的優化效果可能并不完全相同,比較典型的范圍是從 0 變化到 2 或 3。 編譯時使用選項-O 可以告訴 GCC 同時減小代碼的長度和執行時間,其效果等價于-O1。在這一級別上能夠進行的優化類型雖然取決于目標處理器,但一般都會包括線程跳轉 （Thread Jump）和延遲退棧（Deferred Stack Pops）兩種優化。選項-O2 告訴 GCC 除了完成所有-O1 級別的優化之外,同時還要進行一些額外的調整工作,如處理器指令調度等。 選項-O3 則除了完成所有-O2 級別的優化之外,還包括循環展開和其它一些與處理器特性相關的優化工作。 通常來說,數字越大優化的等級越高,同時也就意味著程序的運行 速度越快。許多 Linux 程序員都喜歡使用-O2 選項,因為它在優化長度、編譯時間和代碼大小之間,取得了一個比較理想的平衡點。 下面通過具體實例來感受一下 GCC 的代碼優化功能,所用程序如清單 3 所示。 清單 3：optimize.c

#include <stdio.h> int main(void) { double counter; double result; double temp; for (counter = 0; counter < 2000.0 * 2000.0 * 2000.0counter += (5 - 1) / 4) { temp = counter / 1979; result } printf("Result is %lf\n", result); return 0; } = counter; / 20.0 + 2020;

首先不加任何優化選項進行編譯：

# gcc -Wall optimize.c -o optimize

借助 Linux 提供的 time 命令,可以大致統計出該程序在運行時所需要的時間：

# time ./optimize Result is 400002019.000000 real user sys 0m14.942s 0m14.940s 0m0.000s

接下去使用優化選項來對代碼進行優化處理：

# gcc -Wall -O optimize.c -o optimize

在同樣的條件下再次測試一下運行時間：

# time ./optimize Result is 400002019.000000 real user sys 0m3.256s 0m3.240s 0m0.000s

對比兩次執行的輸出結果不難看出,程序的性能的確得到了很大幅度的改善,由原來的 14 秒縮短到了 3 秒。 這個例子是專門針對 GCC 的優化功能而設計的,因此優化前后程 序的執行速度發生了很大的改變。盡管 GCC 的代碼優化功能非常強大,但作為一名優秀的 Linux 程序員,首先還是要力求能夠手工編寫出高質量的代碼。如果編寫的代碼簡短, 并且邏輯性強,編譯器就不會做更多的工作,甚至根本用不著優化。 優化雖然能夠給程序帶來更好的執行性能,但在如下一些場合中應該避免優化代碼： ◆ 程序開發的時候 優化等級越高,消耗在編譯上的時間就越長,因此在開發的時候最好不要使用優化選項,只有到軟件發行或開發結束的時候,才考慮對最終生成的代碼 進行優化。 ◆ 資源受限的時候一些優化選項會增加可執行代碼的體積,如果程序在運行時能夠申請到的內存資源非常緊張（如一些實時嵌入式設備）,那就不要對代碼進行優化,因 為由這帶來的負面影響可能會產生非常嚴重的后果。 ◆ 跟蹤調試的時候 在對代碼進行優化的時候,某些代碼可能會被刪除或改寫,或者為了取得更佳的性能而進行重組,從而使跟蹤和調試變得異常困難。 調試 一個功能強大的調試器不僅為程序員提供了跟蹤程序執行的手段,而且還可以幫助程序員找到解決問題的方法。對于 Linux 程序員來講,GDB（GNU Debugger）通過與 GCC 的配合使用,為基于 Linux 的軟件開發提供了一個完善的調試環境。 默認情況下,GCC 在編譯時不會將調試符號插入到生成的二進制代碼中,因為這樣會增加可執行文件的大小。如果需要在編譯時生成調試符號信息,可以使用 GCC 的-g 或者 -ggdb 選項。GCC 在產生調試符號時,同樣采用了分級的思路,開發人員可以通過在-g 選項后附加數字 1、2 或 3 來指定在代碼中加入調試信息的多少。默認的級別是 2（-g2）, 此時產生的調試信息包括擴展的符號表、行號、局部或外部變量信息。級別 3（-g3）包含級別 2 中的所有調試信息,以及源代碼中定義的宏。級別 1（-g1）不包含局部變量和與行號有關的調試信息,因此只能夠用于回溯跟蹤和堆棧轉儲之用。 回溯跟蹤指的是監視程序在運行過程中的函數調用歷史,堆棧轉儲則是一種以原始的十六進制格式保存程序 執行環境的方法,兩者都是經常用到的調試手段。 GCC 產生的調試符號具有普遍的適應性,可以被許多調試器加以利用,但如果使用的是 GDB,那么還可以通過-ggdb 選項在生成的二進制代碼中包含 GDB 專用的調試信息。 這 種做法的優點是可以方便 GDB 的調試工作,但缺點是可能導致其它調試器（如 DBX）無法進行正常的調試。選項-ggdb 能夠接受的調試級別和-g 是完全一樣的,它們對輸出的調 試符號有著相同的影響。 需要注意的是,使用任何一個調試選項都會使最終生成的二進制文件的大小急劇增加,同時增加程序在執行時的開銷,因此調試選項通常僅在軟件的開發和調試階段使用。 調試選項對生成代碼大小的影響從下面的對比過程中可以看出來：

# gcc optimize.c -o optimize # ls optimize -l

-rwxrwxr-x 調試選項)

1 xiaowp

xiaowp

11649 Nov 20 08:53 optimize

(未加

# gcc -g optimize.c -o optimize # ls optimize -l -rwxrwxr-x 調試選項) 1 xiaowp xiaowp 15889 Nov 20 08:54 optimize (加入

雖然調試選項會增加文件的大小,但事實上 Linux 中的許多軟件在測試版本甚至最終發行版本中仍然使用了調試選項來進行編譯,這樣做的目的是鼓勵用戶在發現問題時 自己動手解決,是 Linux 的一個顯著特色

下面還是通過一個具體的實例說明如何利用調試符號來分析錯誤,所用程序見清單 4 所示。 清單 4：crash.c

#include <stdio.h> int main(void) { int input =0; printf("Input an integer:"); scanf("%d", input); printf("The integer you input is %d\n", input); return 0; }

編譯并運行上述代碼,會產生一個嚴重的段錯誤（Segmentation fault）如下：

# gcc -g crash.c -o crash # ./crash Input an integer:10

Segmentation fault

為了更快速地發現錯誤所在,可以使用 GDB 進行跟蹤調試,方法如下：

# gdb crash GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) …… (gdb)

當 GDB 提示符出現的時候,表明 GDB 已經做好準備進行調試了,現在可以通過 run 命令讓程序開始在 GDB 的監控下運行：

(gdb) run Starting program: /home/xiaowp/thesis/gcc/code/crash Input an integer:10

Program received signal SIGSEGV, Segmentation fault. 0x4008576b in _IO_vfscanf_internal () from /lib/libc.so.6

仔細分析一下 GDB 給出的輸出結果不難看出,程序是由于段錯誤而導致異常中止的,說明內存操作出了問題,具體發生問題的地方是在調用_IO_vfscanf_internal ( )的時 候。為了得到更加有價值的信息,可以使用 GDB 提供的回溯跟蹤命令 backtrace,執行結果如下：

(gdb) backtrace #0 #1 #2 #3 #4 0x4008576b in _IO_vfscanf_internal () from /lib/libc.so.6 0xbffff0c0 in ?? () 0x4008e0ba in scanf () from /lib/libc.so.6 0x08048393 in main () at crash.c:11 0x40042917 in __libc_start_main () from /lib/libc.so.6

跳過輸出結果中的前面三行,從輸出結果的第四行中不難看出,GDB 已經將錯誤定位到 crash.c 中的第 11 行了。現在仔細檢查一下：

(gdb) frame 3

#3 11

0x08048393 in main () at crash.c:11 scanf("%d", input);

注意：frame 3 中的 3 是上面的 #3 0x08048393 in main () at crash.c:11 的#3

使用 GDB 提供的 frame 命令可以定位到發生錯誤的代碼段,該命令后面跟著的數值可以在 backtrace 命令輸出結果中的行首找到。現在已經發現錯誤所在了,應該將

scanf("%d", input); 改為 scanf("%d", &;input);

完成后就可以退出 GDB 了,命令如下：

(gdb) quit

GDB 的功能遠遠不止如此,它還可以單步跟蹤程序、檢查內存變量和設置斷點等。調試時可能會需要用到編譯器產生的中間結果,這時可以使用-save-temps 選項,讓 GCC 將預處理代碼、匯編代碼和目標代碼都作為文件保存起來。如果想檢查生成的代碼是否能夠通過手工調整的辦法來提高執行性能,在編譯過程中生成的中間文件將會很有幫助,具體情況如下：

# gcc -save-temps foo.c -o foo # ls foo* foo foo.c foo.i foo.s

GCC 支持的其它調試選項還包括-p 和-pg,它們會將剖析（Profiling）信息加入到最終生成的二進制代碼中。剖析信息對于找出程序的性能瓶頸很有幫助,是協助 Linux 程序員開發出高性能程序的有力工具。在編譯時加入-p 選項會在生成的代碼中加入通用剖析工具（Prof）能夠識別的統計信息,而-pg 選項則生成只有 GNU 剖析工具（Gprof） 才能識別的統計信息。

最后提醒一點,雖然 GCC 允許在優化的同時加入調試符號信息,但優化后的代碼對于調試本身而言將是一個很大的挑戰。代碼在經過優化之后,在源程序中聲明和使用的變量很可能不再使用,控制流也可能會突然跳轉到意外的地方,循環語句有可能因為循環展開而變得到處都有,所有這些對調試來講都將是一場噩夢。建議在調試的時候最好不使 用任何優化選項,只有當程序在最終發行的時候才考慮對其進行優化。上次的培訓園地中介紹了 GCC 的編譯過程、警告提示功能、庫依賴、代碼優化和程序調試六個方面的內容。這期是最后的一部分內容。加速 在將源代碼變成可執行文件的過程中,需要經過許多中間步驟,包含預處理、編譯、匯編和連接。這些過程實際上是由不同的程序負責完成的。大多數情況下 GCC 可以為 Linux 程序員完成所有的后臺工作,自動調用相應程序進行處理。 這樣做有一個很明顯的缺點,就是 GCC 在處理每一個源文件時,最終都需要生成好幾個臨時文件才能完成相應的工作,從而無形中導致處理速度變慢。 例如,GCC 在處理一個 源文件時,可能需要一個臨時文件來保存預處理的輸出、 一個臨時文件來保存編譯器的輸出、 一個臨時文件來保存匯編器的輸出,而讀寫這些臨時文件顯然需要耗費一定的時間。 當軟件項目變得非常龐大的時候,花費在這上面的代價可能會變得很沉重。解決的辦法是,使用 Linux 提供的一種更加高效的通信方式—管道。它可以用來同時連接兩個程序,其中一個程序的輸出將被直接作為另一個程序的輸入,這樣就可以避免

使用臨時文件,但編譯時卻需要消耗更多的內存。 在編譯過程中使用管道是由 GCC 的-pipe 選項決定的。下面的這條命令就是借助 GCC 的管道功能來提高編譯速度的：

# gcc -pipe foo.c -o foo

在編譯小型工程時使用管道,編譯時間上的差異可能還不是很明顯,但在源代碼非常多的大型工程中,差異將變得非常明顯。 文件擴展名 在使用 GCC 的過程中,用戶對一些常用的擴展名一定要熟悉,并知道其含義。為了方便大家學習使用 GCC,在此將這些擴展名羅列如下： .c C 原始程序; .C C++原始程序; .cc C++原始程序; .cxx C++原始程序; .m Objective-C 原始程序; .i 已經過預處理的 C 原始程序; .ii 已經過預處理之 C++原始程序; .s 組合語言原始程序; .S 組合語言原始程序; .h 預處理文件(標頭文件); .o 目標文件; .a 存檔文件。 GCC 常用選項 GCC 作為 Linux 下 C/C++重要的編譯環境,功能強大,編譯選項繁多。為了方便大家日后編譯方便,在此將常用的選項及說明羅列出來如下： -c 通知 GCC 取消鏈接步驟,即編譯源碼并在最后生成目標文件; -Dmacro 定義指定的宏,使它能夠通過源碼中的#ifdef 進行檢驗; -E 不經過編譯預處理程序的輸出而輸送至標準輸出; -g3 獲得有關調試程序的詳細信息,它不能與-o 選項聯合使用; -Idirectory 在包含文件搜索路徑的起點處添加指定目錄; -llibrary 提示鏈接程序在創建最終可執行文件時包含指定的庫; -O、-O2、-O3 將優化狀態打開,該選項不能與-g 選項聯合使用; -S 要求編譯程序生成來自源代碼的匯編程序輸出; -v 啟動所有警報; -Wall 在發生警報時取消編譯操作,即將警報看作是錯誤; -Werror 在發生警報時取消編譯操作,即把報警當作是錯誤; -w 禁止所有的報警。 小結 GCC 是在 Linux 下開發程序時必須掌握的工具之一。本文對 GCC 做了一個簡要的介紹,主要講述了如何使用 GCC 編譯程序、產生警告信息、調試程序和加快 GCC 的編譯速 度。對所有希望早日跨入 Linux 開發者行列的人來說,GCC 就是成為一名優秀的 Linux 程序員的起跑線