• <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 閱讀(265) 評論(0)  編輯 收藏 引用

            <2025年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            導航

            統計

            公告

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

            常用鏈接

            留言簿(4)

            隨筆分類

            隨筆檔案

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            成人国内精品久久久久影院| 狠狠色综合网站久久久久久久高清| 99精品国产综合久久久久五月天| 久久这里都是精品| 国产精品99久久久久久人| 亚洲国产精品综合久久网络| 亚洲精品无码久久千人斩| 91麻豆精品国产91久久久久久| 天堂无码久久综合东京热| av无码久久久久不卡免费网站| 国产精品一区二区久久精品涩爱| 久久99国产精品尤物| 国产成人精品久久二区二区| 国内精品伊人久久久影院| 久久精品国产69国产精品亚洲| 久久99精品久久久久久hb无码| 狠狠色丁香久久婷婷综合蜜芽五月| 国产亚洲精午夜久久久久久| 久久综合九色综合久99| 久久精品国产一区二区| 91亚洲国产成人久久精品网址| 久久亚洲AV成人无码电影| 亚洲国产精品无码成人片久久| 97久久超碰国产精品旧版| 国产精品久久久久久| 亚洲国产成人乱码精品女人久久久不卡 | 99久久综合国产精品免费| 国产A三级久久精品| 久久精品成人免费看| 久久精品亚洲福利| 久久久久久国产精品无码超碰| 91精品免费久久久久久久久| 久久伊人精品一区二区三区| 99久久国产综合精品麻豆| 成人午夜精品无码区久久| 久久亚洲精品无码播放| 丰满少妇高潮惨叫久久久| 久久午夜无码鲁丝片秋霞| 狠狠色丁香久久婷婷综合_中| 9999国产精品欧美久久久久久| AV狠狠色丁香婷婷综合久久 |