gcc/g++等編譯器 編譯原理: 預處理,編譯,彙編,鏈接各步驟詳解

概述

C和C++編譯器是集成的,編譯一般分爲四個步驟:

  1. 預處理(preprocessing)  ----------------- cpp/ gcc -E 
  2. 編譯(compilation) ------------------ cc1 / gcc -S
  3. 彙編(assembly)  -------------------- as
  4. 連接(linking) --------------------- ld 




gcc

  認爲預處理的文件是(.i)是C文件,並且設定C形式的連接;

g++

  認爲預處理的文件是(.i)是C++文件,並且設定C++形式的連接;

 

源文件後綴名的一些含義和後續的操作:

  • .c       C源程序        預處理,編譯,彙編
  • .C      C++源程序        預處理,編譯,彙編
  • .cc       C++源程序  
  • .cxx       C++源程序        預處理,編譯,彙編
  • .m       Objective-C源程序   預處理,編譯,彙編
  • .i       預處理後的C文件     編譯,彙編
  • .ii      預處理後的C++文件   編譯,彙編
  • .s      彙編語言源程序     彙編
  • .S      彙編語言源程序     預處理,彙編
  • .h      預處理器文件      通常不出現在命令行上  


其他後綴名的文件被傳遞給連接器(linker).通常包括:


  .o 目標文件(Object file)


  .a 歸檔庫文件(Archive file)

 

轉載請註明出處: http://blog.csdn.net/elfprincexu


二、具體介紹一下GCC編譯步驟

首先,有以下hello.c源代碼

#include<stdio.h>

int main()
{
      printf("Hello! This is our embedded world!\n");

      return 0;
}

(1)預處理階段

在該階段,編譯器將上述代碼中的stdio.h編譯進來,並且用戶可以使用Gcc的選項”-E”進行查看,該選項的作用是讓Gcc在預處理結束後停止編譯過程。預處理階段主要處理#include和#define,它把#include包含進來的.h 文件插入到#include所在的位置,把源程序中使用到的用#define定義的宏用實際的字符串代替,我們可以用-E選項要求gcc只進行預處理而不進行後面的三個階段,


 注意 : Gcc指令的一般格式爲:Gcc [選項] 要編譯的文件 [選項] [目標文件]

 其中,目標文件可缺省,Gcc默認生成可執行的文件,命爲:編譯文件.out
 

[root@localhost Gcc]# Gcc –E hello.c –o hello.i

 

在此處,選項"-o"是指目標文件,".i"文件爲已經過預處理的C原始程序。以下列出了hello.i文件的部分內容:

typedef int (*__gconv_trans_fct) (struct __gconv_step *,

         struct __gconv_step_data *, void *,

         __const unsigned char *,

         __const unsigned char **,

         __const unsigned char *, unsigned char **,

         size_t *);

…

# 2 "hello.c" 2

int main()

{

 printf("Hello! This is our embedded world!\n");

 return 0;

} 

由此可見,Gcc確實進行了預處理,它把”stdio.h”的內容插入到hello.i文件中。

 

(2)編譯階段

接下來進行的是編譯階段,在這個階段中,Gcc首先要檢查代碼的規範性、是否有語法錯誤等,以確定代碼的實際要做的工作,在檢查無誤後,Gcc把代碼翻譯成彙編語言。用戶可以使用”-S”選項來進行查看,該選項只進行編譯而不進行彙編,生成彙編代碼。

編譯階段是最重要的階段,在這個階段GCC首先檢查語法然後把由上步生成的*.i編譯成*.s文件。我們可以用如下命令告訴gcc進行這一步處理,gcc -S hello.i -o hello.s,-S選項告訴gcc把hello.i編譯成.s文件;

上面這兩步的輸出文件都是文本文件,我們可以用諸如cat的文本處理等命令閱讀這些輸出文件。
這個階段可以接收.c和.i類型的文件

[root@localhost Gcc]# Gcc –S hello.i –o hello.s


以下列出了hello.s的內容,可見Gcc已經將其轉化爲彙編了,感興趣的讀者可以分析一下這一行簡單的C語言小程序是如何用匯編代碼實現的。

 .file   "hello.c"

     .section    .rodata

     .align 4

.LC0:

     .string     "Hello! This is our embedded world!"

     .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 puts

     addl $16, %esp

     movl $0, %eax

     leave

     ret

     .size   main, .-main

     .ident  "GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)"

     .section    .note.GNU-stack,"",@progbits

 


(3)彙編階段

彙編階段把*.s文件翻譯成二進制機器指令文件*.o,如命令gcc -c hello.s -o hello.o,其中-c告訴gcc進行彙編處理。這步生成的文件是二進制文件,直接用文本工具打開看到的將是亂碼,我們需要反彙編工具如GDB的幫助才能讀懂它;
這個階段接收.c, .i, .s的文件都沒有問題。比如gcc -c hello.i -o hello.o等

彙編階段是把編譯階段生成的”.s”文件轉成目標文件,讀者在此可使用選項”-c”就可看到彙編代碼已轉化爲”.o”的二進制目標代碼了。如下所示: 

[root@localhost Gcc]# Gcc –c hello.s –o hello.o

 

(4)鏈接階段

在成功編譯之後,就進入了鏈接階段。在這裏涉及到一個重要的概念:函數庫。

讀者可以重新查看這個小程序,在這個程序中並沒有定義”printf”的函數實現,且在預編譯中包含進的”stdio.h”中也只有該函數的聲明,而沒有定義函數的實現,那麼,是在哪裏實現”printf”函數的呢?最後的答案是:系統把這些函數實現都被做到名爲libc.so.6的庫文件中去了,在沒有特別指定時,Gcc會到系統默認的搜索路徑”/usr/lib”下進行查找,也就是鏈接到libc.so.6庫函數中去,這樣就能實現函數”printf”了,而這也就是鏈接的作用。


函數庫一般分爲靜態庫和動態庫兩種。

  • 靜態庫是指編譯鏈接時,把庫文件的代碼全部加入到可執行文件中,因此生成的文件比較大,但在運行時也就不再需要庫文件了。其後綴名一般爲”.a”。
  • 動態庫與之相反,在編譯鏈接時並沒有把庫文件的代碼加入到可執行文件中,而是在程序執行時由運行時鏈接文件加載庫,這樣可以節省系統的開銷。動態庫一般後綴名爲”.so”,如前面所述的libc.so.6就是動態庫。Gcc在編譯時默認使用動態庫。

說下生成靜態庫的方法:
	ar cr libxxx.a file1.o file2.o
就是把file1.o和file2.o打包生成libxxx.a靜態庫
使用的時候
	gcc test.c -L/path -lxxx -o test

動態庫的話:
	gcc -fPIC -shared file1.c -o libxxx.so
也可以分成兩部來寫:
	gcc -fPIC file1.c -c //這一步生成file1.o
	gcc -shared file1.o -o libtest.so


效果是一樣的。
用的時候和上面的靜態庫的用法一樣
但是到了運行程序的時候,需要指定動態庫的位置,可以環境變量來指定
export LD_LIBRARY_PATH=path,否則會提示找不到動態庫的位置

由於鏈接動態庫和靜態庫的時候使用的方法是一樣的,所以如果在庫中有同名的靜態庫文件和動態庫文件,比如libtest.a和libtest.so,根據gcc鏈接時默認優先選擇動態庫,會鏈接libtest.so,如果想要讓gcc選擇鏈接libtest.a那麼需要指定一個選項,就是-static,這樣就會強制gcc找靜態庫文件了。


靜態庫鏈接時搜索路徑順序:

  • 1. ld會去找GCC命令中的參數-L
  • 2. 再找gcc的環境變量LIBRARY_PATH
  • 3. 再找內定目錄 /lib /usr/lib /usr/local/lib 這是當初compile gcc時寫在程序內的

動態鏈接時、執行時搜索路徑順序:

  • 1. 編譯目標代碼時指定的動態庫搜索路徑
  • 2. 環境變量LD_LIBRARY_PATH指定的動態庫搜索路徑
  • 3. 配置文件/etc/ld.so.conf中指定的動態庫搜索路徑
  • 4. 默認的動態庫搜索路徑/lib
  • 5. 默認的動態庫搜索路徑/usr/lib


有關環境變量:

  • LIBRARY_PATH環境變量:指定程序靜態鏈接庫文件搜索路徑
  • LD_LIBRARY_PATH環境變量:指定程序動態鏈接庫文件搜索路徑


完成了鏈接之後,Gcc就可以生成可執行文件,如下所示。

[root@localhost Gcc]# Gcc hello.o –o hello

 

運行該可執行文件,出現正確的結果如下。 

[root@localhost Gcc]# ./hello

Hello! This is our embedded world!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章