轉載http://apps.hi.baidu.com/share/detail/32660500
C/C++程序編譯步驟 如何生成可執行文件
?????*******************************************************篇一********************************************************************************************?
???? 電子計算機所使用的是由“0”和“1”組成的二進制數,二進制是計算機的語言的基礎。計算機發明之初,人們只能降貴紆尊,用計算機的語言去命令計算機干這干那,一句話,就是寫出一串串由“0”和“1”組成的指令序列交由計算機執行,這種語言,就是機器語言。想象一下老前輩們在打孔機面前數著一個一個孔的情景,噓,小聲點,你的驚嚇可能使他們錯過了一個孔,結果可能是導致一艘飛船飛離軌道阿。
??????? 為了減輕使用機器語言編程的痛苦,人們進行了一種有益的改進:用一些簡潔的英文字母、符號串來替代一個特定的指令的二進制串,比如,用“A D D”代表加法,“M O V”代表數據傳遞等等,這樣一來,人們很容易讀懂并理解程序在干什么,糾錯及維護都變得方便了,這種程序設計語言就稱為匯編語言,即第二代計算機語言。然而計算機是不認識這些符號的,這就需要一個專門的程序,專門負責將這些符號翻譯成二進制數的機器語言,這種翻譯程序被稱為匯編程序。因為匯編指令和機器語言之間有著一一對應的關系,這可比英譯漢或漢譯英簡單多了。
????? 高級語言是偏向人,按照人的思維方式設計的,機器對這些可是莫名奇妙,不知所謂。魚與熊掌的故事在計算機語言中發生了。于是必須要有一個橋梁來銜接兩者,造橋可不是一件簡單的事情。當你越想方便,那橋就得越復雜。那高級語言是如何變成機器語言的呢,這個過程讓我慢慢道來。
?????? 編譯:將源代碼轉換為機器可認識代碼的過程。編譯程序讀取源程序(字符流),對之進行詞法和語法的分析,將高級語言指令轉換為功能等效的匯編代碼,再由匯編程序轉換為機器語言,并且按照操作系統對可執行文件格式的要求鏈接生成可執行程序。
C源程序->編譯預處理->編譯->優化程序->匯編程序->鏈接程序->可執行文件 ?
1.編譯預處理? 讀取c源程序,對其中的偽指令(以#開頭的指令)和特殊符號進行處理。?
偽指令主要包括以下四個方面
(1)宏定義指令,如# define Name TokenString,#undef等。對于前一個偽指令,預編譯所要作得的是將程序中的所有Name用TokenString替換,但作為字符串常量的Name則不被替換。對于后者,則將取消對某個宏的定義,使以后該串的出現不再被替換。?
(2)條件編譯指令,如#ifdef,#ifndef,#else,#elif,#endif,等等。這些偽指令的引入使得程序員可以通過定義不同的宏來決定編譯程序對哪些代碼進行處理。預編譯程序將根據有關的文件,將那些不必要的代碼過濾掉。?
(3)頭文件包含指令,如#include "FileName"或者#include <FileName>等。在頭文件中一般用偽指令#define定義了大量的宏(最常見的是字符常量),同時包含有各種外部符號的聲明。采用頭文件的目的主要是為了使某些定義可以供多個不同的C源程序使用。因為在需要用到這些定義的C源程序中,只需加上一條#include語句即可,而不必再在此文件中將這些定義重復一遍。預編譯程序將把頭文件中的定義統統都加入到它所產生的輸出文件中,以供編譯程序對之進行處理。?
包含到c源程序中的頭文件可以是系統提供的,這些頭文件一般被放在/usr/include目錄下。在程序中#include它們要使用尖括號(<>)。另外開發人員也可以定義自己的頭文件,這些文件一般與c源程序放在同一目錄下,此時在#include中要用雙引號("")。
(4)特殊符號,預編譯程序可以識別一些特殊的符號。例如在源程序中出現的LINE標識將被解釋為當前行號(十進制數),FILE則被解釋為當前被編譯的C源程序的名稱。預編譯程序對于在源程序中出現的這些串將用合適的值進行替換。
預編譯程序所完成的基本上是對源程序的“替代”工作。經過此種替代,生成一個沒有宏定義、沒有條件編譯指令、沒有特殊符號的輸出文件。這個文件的含義同沒有經過預處理的源文件是相同的,但內容有所不同。下一步,此輸出文件將作為編譯程序的輸出而被翻譯成為機器指令。
2.編譯階段
經過預編譯得到的輸出文件中,將只有常量。如數字、字符串、變量的定義,以及C語言的關鍵字,如main,if,else,for,while,{,},+,-,*,\,等等。預編譯程序所要作得工作就是通過詞法分析和語法分析,在確認所有的指令都符合語法規則之后,將其翻譯成等價的中間代碼表示或匯編代碼。?
3.優化階段
優化處理是編譯系統中一項比較艱深的技術。它涉及到的問題不僅同編譯技術本身有關,而且同機器的硬件環境也有很大的關系。優化一部分是對中間代碼的優化。這種優化不依賴于具體的計算機。另一種優化則主要針對目標代碼的生成而進行的。上圖中,我們將優化階段放在編譯程序的后面,這是一種比較籠統的表示。
對于前一種優化,主要的工作是刪除公共表達式、循環優化(代碼外提、強度削弱、變換循環控制條件、已知量的合并等)、復寫傳播,以及無用賦值的刪除,等等。
后一種類型的優化同機器的硬件結構密切相關,最主要的是考慮是如何充分利用機器的各個硬件寄存器存放的有關變量的值,以減少對于內存的訪問次數。另外,如何根據機器硬件執行指令的特點(如流水線、RISC、CISC、VLIW等)而對指令進行一些調整使目標代碼比較短,執行的效率比較高,也是一個重要的研究課題。?
經過優化得到的匯編代碼必須經過匯編程序的匯編轉換成相應的機器指令,方可能被機器執行。?
4.匯編過程
匯編過程實際上指把匯編語言代碼翻譯成目標機器指令的過程。對于被翻譯系統處理的每一個C語言源程序,都將最終經過這一處理而得到相應的目標文件。目標文件中所存放的也就是與源程序等效的目標的機器語言代碼。
?目標文件由段組成。通常一個目標文件中至少有兩個段:
代碼段? 該段中所包含的主要是程序的指令。該段一般是可讀和可執行的,但一般卻不可寫。??
數據段? 主要存放程序中要用到的各種全局變量或靜態的數據。一般數據段都是可讀,可寫,可執行的。
UNIX環境下主要有三種類型的目標文件:?
(1)可重定位文件? 其中包含有適合于其它目標文件鏈接來創建一個可執行的或者共享的目標文件的代碼和數據。
?(2)共享的目標文件? 這種文件存放了適合于在兩種上下文里鏈接的代碼和數據。第一種事鏈接程序可把它與其它可重定位文件及共享的目標文件一起處理來創建另一個目標文件;第二種是動態鏈接程序將它與另一個可執行文件及其它的共享目標文件結合到一起,創建一個進程映象。
?(3)可執行文件? 它包含了一個可以被操作系統創建一個進程來執行之的文件。
匯編程序生成的實際上是第一種類型的目標文件。對于后兩種還需要其他的一些處理方能得到,這個就是鏈接程序的工作了。
5.鏈接程序
由匯編程序生成的目標文件并不能立即就被執行,其中可能還有許多沒有解決的問題。例如,某個源文件中的函數可能引用了另一個源文件中定義的某個符號(如變量或者函數調用等);在程序中可能調用了某個庫文件中的函數,等等。所有的這些問題,都需要經鏈接程序的處理方能得以解決。
鏈接程序的主要工作就是將有關的目標文件彼此相連接,也即將在一個文件中引用的符號同該符號在另外一個文件中的定義連接起來,使得所有的這些目標文件成為一個能夠被操作系統裝入執行的統一整體。
根據開發人員指定的同庫函數的鏈接方式的不同,鏈接處理可分為兩種:?
(1)靜態鏈接? 在這種鏈接方式下,函數的代碼將從其所在地靜態鏈接庫中被拷貝到最終的可執行程序中。這樣該程序在被執行時這些代碼將被裝入到該進程的虛擬地址空間中。靜態鏈接庫實際上是一個目標文件的集合,其中的每個文件含有庫中的一個或者一組相關函數的代碼。
?(2)動態鏈接? 在此種方式下,函數的代碼被放到稱作是動態鏈接庫或共享對象的某個目標文件中。鏈接程序此時所作的只是在最終的可執行程序中記錄下共享對象的名字以及其它少量的登記信息。在此可執行文件被執行時,動態鏈接庫的全部內容將被映射到運行時相應進程的虛地址空間。動態鏈接程序將根據可執行程序中記錄的信息找到相應的函數代碼。?
???? 對于可執行文件中的函數調用,可分別采用動態鏈接或靜態鏈接的方法。使用動態鏈接能夠使最終的可執行文件比較短小,并且當共享對象被多個進程使用時能節約一些內存,因為在內存中只需要保存一份此共享對象的代碼。但并不是使用動態鏈接就一定比使用靜態鏈接要優越。在某些情況下動態鏈接可能帶來一些性能上損害。
? 經過上述五個過程,C源程序就最終被轉換成可執行文件了
上一節我們介紹了編程語言的種類,其中包括機器語言、匯編語言和高級語言。
?本文來自:我愛研發網(52RD.com) - R&D大本營 詳細出處:http://www.52rd.com/Blog/Archive_Thread.asp?SID=5196
*************************************篇二*************************************************************************************************************************
C/C++程序編譯步驟詳解 來源: ChinaUnix博客 日期: 2007.04.24 07:30 (共有0 條評論)?我要評論 ? C/C++程序編譯步驟詳解 C/C++語言很多人都比較熟悉,這基本上是每位大學生必學的一門編程語言,通常還都是作為程序設計入門語言學的,并且課程大多安排在大一。剛上大學,孩子們還都很乖,學習也比較認真,用心。所以,C/C++語言掌握地也都不錯,不用說編譯程序,就是寫個上幾百行的程序都不在話下,但是他們真的知道C/C++程序編譯的步驟么? 我想很多人都不甚清楚,如果他接下來學過“編譯原理”,也許能說個大概。VC的“舒適”開發環境屏蔽了很多編譯的細節,這無疑降低了初學者的入門門檻,但是也“剝奪”了他們“知其所以然”的權利,致使很多東西只能死記硬背,遇到相關問題就“丈二”。實際上,我也是在學習Linux環境下編程的過程中才逐漸弄清楚C/C++源代碼是如何一步步變成可執行文件的。 總體來說,C/C++源代碼要經過:預處理、編譯、匯編和連接四步才能變成相應平臺下的可執行文件。大多數時候,程序員通過一個命令就能完成上述四個步驟。比如下面這段C的“Hello world!”代碼: File: hw.c #include stdio.h> int main(int argc, char *argv[]) { ? ?? ???printf("Hello World!\n"); ? ?? ???return 0; } 如果用gcc編譯,只需要一個命令就可以生成可執行文件hw: xiaosuo@gentux hw $ gcc -o hw hw.c xiaosuo@gentux hw $ ./hw Hello World!? 我們可以用-v參數來看看gcc到底在背后都做了些什么動作: Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/specs Configured with: /var/tmp/portage/sys-devel/gcc-3.4.6-r2/work/gcc-3.4.6/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.6 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10) /usr/libexec/gcc/i686-pc-linux-gnu/3.4.6/cc1 -quiet -v hw.c -quiet -dumpbase hw.c -mtune=pentiumpro -auxbase hw -version -o /tmp/ccYB6UwR.s ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include ...> search starts here: /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include /usr/include End of search list. GNU C version 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10) (i686-pc-linux-gnu) ? ?? ???compiled by GNU C version 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9). GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=97004 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o /tmp/ccq8uGED.o /tmp/ccYB6UwR.s GNU assembler version 2.17 (i686-pc-linux-gnu) using BFD version 2.17 /usr/libexec/gcc/i686-pc-linux-gnu/3.4.6/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hw /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../crt1.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/crtbegin.o -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.6 -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.6 -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../.. /tmp/ccq8uGED.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/crtend.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../crtn.o 稍微整理一下,去掉一些冗余信息后,如下: cc1 hw.c -o /tmp/ccYB6UwR.s as -o /tmp/ccq8uGED.o /tmp/ccYB6UwR.s ld -o hw /tmp/ccq8uGED.o 以上三個命令分別對應于編譯步驟中的預處理+編譯、匯編和連接。預處理和編譯還是放在了一個命令(cc1)中進行的,可以把它再次拆分為以下兩步: cpp -o hw.i hw.c cc1 hw.i -o /tmp/ccYB6UwR.s 一個精簡過的能編譯以上hw.c文件的Makefile如下: .PHONY: clean all: hw hw: hw.o ? ?? ???ld -dynamic-linker /lib/ld-linux.so.2 -o hw /usr/lib/crt1.o \ ? ?? ?? ?? ?? ? /usr/lib/crti.o \ ? ?? ?? ?? ?? ? /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/crtbegin.o \ ? ?? ?? ?? ?? ? hw.o -lc \ ? ?? ?? ?? ?? ? /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/crtend.o \ ? ?? ?? ?? ?? ? /usr/lib/crtn.o hw.o: hw.s ? ?? ???as -o hw.o hw.s hw.s: hw.i ? ?? ???/usr/libexec/gcc/i686-pc-linux-gnu/3.4.6/cc1 -o hw.s hw.c hw.i: hw.c ? ?? ???cpp -o hw.i hw.c clean: ? ?? ???rm -rf hw.i hw.s hw.o 當然,上面Makefile中的一些路徑是我系統上的具體情況,你的可能與我的不同。 接下來我們按照編譯順序看看編譯器每一步都做了什么。 首先是預處理,預處理后的文件hw.i: # 1 "hw.c" # 1 "" # 1 "" ... __extension__ typedef __quad_t __off64_t; __extension__ typedef int __pid_t; __extension__ typedef struct { int __val[2]; } __fsid_t; ... extern int remove (__const char *__filename) __attribute__ ((__nothrow__)); extern int rename (__const char *__old, __const char *__new) __attribute__ ((__nothrow__)); ... int main(int argc, char *argv[]) { printf("Hello World!\n"); return 0; } 注:由于文件比較大,所以只留下了少部分具有代表性的內容。 可以看見預處理器把所有要包含(include)的文件(包括遞歸包含的文件)的內容都添加到了原始的C源文件中,然后把其輸出到輸出文件,除此之外,它還展開了所有的宏定義,所以在預處理器的輸出文件中你將找不到任何宏。這也提供了一個查看宏展開結果的簡便方法。 第二步“編譯”,就是把C/C++代碼“翻譯”成匯編代碼: .file "hw.c" ? ?? ???.section .rodata .LC0: ? ?? ???.string "Hello World!\n" ? ?? ???.text .globl main ? ?? ???.type main, @function main: ? ?? ???pushl %ebp ? ?? ???movl %esp, %ebp ? ?? ???subl $8, %esp ? ?? ???andl $-16, %esp ? ?? ???movl $0, %eax ? ?? ???addl $15, %eax ? ?? ???addl $15, %eax ? ?? ???shrl $4, %eax ? ?? ???sall $4, %eax ? ?? ???subl %eax, %esp ? ?? ???subl $12, %esp ? ?? ???pushl $.LC0 ? ?? ???call printf ? ?? ???addl $16, %esp ? ?? ???movl $0, %eax ? ?? ???leave ? ?? ???ret ? ?? ???.size main, .-main ? ?? ???.section .note.GNU-stack,"",@progbits ? ?? ???.ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10)" 這個匯編文件比預處理后的C/C++文件小了很多,去除了很多不必要的東西,比如說沒用到的類型聲明和函數聲明等。 第三步“匯編”,將第二步輸出的匯編代碼翻譯成符合一定格式的機器代碼,在Linux上一般表現為ELF目標文件。 xiaosuo@gentux hw $ file hw.o hw.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped 最后一步“連接”,將上步生成的目標文件和系統庫的目標文件和庫文件連接起來,最終生成了可以在特定平臺運行的可執行文件。為什么還要連接系統庫中的某些目標文件(crt1.o, crti.o等)呢?這些目標文件都是用來初始化或者回收C運行時環境的,比如說堆內存分配上下文環境的初始化等,實際上crt也正是C RunTime的縮寫。這也暗示了另外一點:程序并不是從main函數開始執行的,而是從crt中的某個入口開始的,在Linux上此入口是_start。以上Makefile生成的是動態連接的可執行文件,如果要生成靜態連接的可執行文件需要將Makefile中的相應段修改: hw: hw.o ? ? ld -m elf_i386 -static -o hw /usr/lib/crt1.o \ ? ?? ???/usr/lib/crti.o \ ? ?? ???/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/crtbeginT.o \ ? ?? ???-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.6 \ ? ?? ???-L/usr/i686-pc-linux-gnu/lib \ ? ?? ???-L/usr/lib/ \ ? ?? ???hw.o --start-group -lgcc -lgcc_eh -lc --end-group \ ? ?? ???/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/crtend.o \ ? ?? ???/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../crtn.o 至此,一個可執行文件才最終創建完成。通常的項目中并不需要把編譯過程分得如此之細,前三步一般是合為一體的,在Makefile中表現如下: hw.o: hw.c ? ? gcc -o hw.o -c hw.c 實際上,如果對hw.c進行了什么更改,那么前三步大多數情況下都是不可避免的。所以把他們寫在一起也并沒有什么壞處,相反倒可以用--pipe參數告訴編譯器用管道替代臨時文件,從而提升編譯的效率。
總結
以上是生活随笔 為你收集整理的C/C++程序从编译到最终生成可执行文件的过程分析 的全部內容,希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔 網站內容還不錯,歡迎將生活随笔 推薦給好友。