• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            現代編譯器常見的編譯過程

            peakflys注:本文轉載自http://blog.sina.com.cn/s/blog_49ec372801008fzt.html ,其中很多對gcc的講解很實用。

            現代編譯器常見的編譯過程:
            源文件-->預處理-->編譯/優化-->匯編-->鏈接-->可執行文件

            對于gcc而言:
            第一步 預處理
            命令: gcc -o test.i -E test.c
            或者 cpp -o test.i test.c (這里cpp不是指c plus plus,而是the C Preprocessor)
            結果: 生成預處理后的文件test.i(可以打開后與預處理前進行比對,當然長度會嚇你一跳)
            注解: 此步讀取c源程序,對偽指令和特殊符號進行處理。包括宏(peakflys注:通過加入-E -P 可以輕松的看到程序中宏替換后的代碼,便于編寫復雜宏時對照),條件編譯,包含的頭文件,以及一些特殊符號。基本上是一個replace的過程。

            第二步 編譯及優化
            命令: gcc -o test.s -S test.i
            或者 /路徑/cc1 -o test.s test.i
            結果: 生成匯編文件test.s(可打開后查看源文件生成的匯編碼)
            注解: 此步通過詞法和語法分析,確認所有指令符合語法規則(否則報編譯錯),之后翻譯成對應的中間碼,在linux中被稱為RTL(Register Transfer Language),通常是平臺無關的,這個過程也被稱為編譯前端。編譯后端對RTL樹進行裁減,優化,得到在目標機上可執行的匯編代碼。使用不同的優化 編譯選項,可以看到在不同優化級別下的代碼。了解編譯器對你寫的代碼到底做了什么。

            第三步 匯編
            命令: gcc -o test.o -c test.s
            或者 as -o test.o test.s
            結果: 生成目標機器指令文件test.o(可用objdump查看)
            注解: 此步把匯編語言代碼翻譯成目標機器指令, 用file test.o 可以看到test.o是一個relocatable的ELF文件,通常包含.text .rodata代碼段和數據段。可用readelf -r test.o查看需要relocation的部分。gcc采用as作為其匯編器,所以匯編碼是AT&T格式的,而不是Intel格式,所以在用 gcc編譯嵌入式匯編時,也要采用AT&T格式。

            第四步 鏈接
            命令: gcc -o test test.o
            或者 ld -o test test.o
            結果: 生成可執行文件test (可用objdump查看)
            注解: 此步將在一個文件中引用的符號同在另外一個文件中該符號的定義鏈接起來,使得所有的這些目標文件鏈接成為一個能被操作系統加載到內存的執行體。(如果有不 到的符號定義,或者重復定義等,會報鏈接錯)。用file test 可以看到test是一個executable的ELF文件。

            當然鏈接的時候還會用到靜態鏈接庫,和動態連接庫。靜態庫和動態庫都是.o目標文件的集合,但是使用相差很遠。
            靜態庫:
            命令: ar -v -q test.a test.o
            結果: 生成靜態鏈接庫test.a
            注解: 靜態庫是在鏈接過程中將相關代碼提取出來加入可執行文件的庫(即在鏈接的時候將函數的代碼將從其所在地靜態鏈接庫中被拷貝到最終的可執行程序中),ar只是將一些別的文件集合到一個文件中。可以打包,當然也可以解包。(peakflys注:通常自己編寫的常用底層都以靜態庫的形式提供,這樣一則減少上層邏輯的編譯時間,二則只需要在每個使用處包含文件名即可,不用關注庫文件的具體路徑)

            動態庫:
            命令: gcc -shared test.so test.o
            或者/PATH/collect2 -shared test.so test.o (省略若干參數)
            結果: 生成動態連接庫test.so
            注解: 動態庫在鏈接時只創建一些符號表,而在運行的時候才將有關庫的代碼裝入內存,映射到運行時相應進程的虛地址空間(peakflys注:通過這種特點,我們可以設想,如果以后服務器的功能邏輯都以這種方式提供,那么對于C++這種編譯型語言也可以像解釋型的腳本語言一樣達到不停服的功能更新)。如果出錯,如找不到對應的.so文件,會 在執行的時候報動態連接錯(可用LD_LIBRARY_PATH指定路徑)。用file test.so可以看到test.so是shared object的ELF文件。而靜態庫test.a只是一個集合包。
            peakflys注:linux下,通常靜態庫以.a方式存在,動態庫以.so方式存在;windows下靜態庫以.lib存在,動態庫以.dll方式存在。
            所以當gcc編譯源文件時經歷了test.c -> test.i -> RTL -> test.s -> test.o -> test的過程。當然以上各步可以一步或若干步一起完成,如gcc -o test test.c直接得到可執行文件。當然也可以加上-v來查看在這個過程中,gcc總共做了多少事。

            posted on 2013-04-10 09:57 peakflys 閱讀(254) 評論(0)  編輯 收藏 引用

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導航

            統計

            公告

            人不淡定的時候,就愛表現出來,敲代碼如此,偶爾的靈感亦如此……

            常用鏈接

            留言簿(4)

            隨筆分類

            隨筆檔案

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            色综合合久久天天综合绕视看| 91麻豆国产精品91久久久| 一本色道久久综合狠狠躁| 久久天天躁狠狠躁夜夜躁2014| 久久强奷乱码老熟女网站| 精品久久久久久久久中文字幕| AAA级久久久精品无码区| 久久这里只有精品首页| 99久久人妻无码精品系列蜜桃 | 午夜精品久久久久9999高清| 久久中文字幕人妻丝袜| 精品国产一区二区三区久久| 亚洲色欲久久久久综合网| 久久久久久亚洲精品成人| 天堂无码久久综合东京热| 精品综合久久久久久888蜜芽| 久久精品国产99久久香蕉| 婷婷五月深深久久精品| 久久这里有精品视频| 2021久久国自产拍精品| 久久久久精品国产亚洲AV无码| 国产激情久久久久影院小草| 亚洲中文精品久久久久久不卡| 久久夜色撩人精品国产| 国产日产久久高清欧美一区| 久久亚洲AV成人出白浆无码国产 | 久久丝袜精品中文字幕| 久久99精品国产| 99久久精品国内| 久久香蕉国产线看观看精品yw| 久久久久亚洲av成人网人人软件 | 中文无码久久精品| 理论片午午伦夜理片久久| 欧美亚洲另类久久综合| 成人免费网站久久久| 久久国产高潮流白浆免费观看| 亚洲精品国产字幕久久不卡| 国产精品久久新婚兰兰| 久久无码AV中文出轨人妻| 久久人做人爽一区二区三区 | 91麻精品国产91久久久久|