• <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>

            平凡的天才

            目的是為人類造福
            posts - 20, comments - 41, trackbacks - 0, articles - 6
              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

            詳解compile & link

            Posted on 2007-01-06 10:50 平凡的天才 閱讀(2175) 評論(1)  編輯 收藏 引用
            轉(zhuǎn)載自http://www.shnenglu.com/shifan3/archive/2007/01/05/17325.html
            有些人寫C/C++(以下假定為C++)程序,對unresolved external link或者duplicated external simbol的錯(cuò)誤信息不知所措(因?yàn)檫@樣的錯(cuò)誤信息不能定位到某一行)。或者對語言的一些部分不知道為什么要(或者不要)這樣那樣設(shè)計(jì)。了解本文之后,或許會有一些答案。
            ??? 首先看看我們是如何寫一個(gè)程序的。如果你在使用某種IDE(Visual Studio,Elicpse,Dev C++等),你可能不會發(fā)現(xiàn)程序是如何組織起來的(很多人因此而反對初學(xué)者使用IDE)。因?yàn)槭褂肐DE,你所做的事情,就是在一個(gè)項(xiàng)目里新建一系列的.cpp和.h文件,編寫好之后在菜單里點(diǎn)擊“編譯”,就萬事大吉了。但其實(shí)以前,程序員寫程序不是這樣的。他們首先要打開一個(gè)編輯器,像編寫文本文件一樣的寫好代碼,然后在命令行下敲
            ?? ?cc 1.cpp -o 1.o
            ?? ?cc 2.cpp -o 2.o
            ?? ?cc 3.cpp -o 3.o
            這里cc代表某個(gè)C/C++編譯器,后面緊跟著要編譯的cpp文件,并且以-o指定要輸出的文件(請?jiān)徫覜]有使用任何一個(gè)流行編譯器作為例子)。這樣當(dāng)前目錄下就會出現(xiàn):
            ?? ?1.o 2.o 3.o
            最后,程序員還要鍵入
            ?? ?link 1.o 2.o 3.o -o a.out
            來生成最終的可執(zhí)行文件a.out。現(xiàn)在的IDE,其實(shí)也同樣遵照著這個(gè)步驟,只不過把一切都自動化了。
            ??? 讓我們來分析上面的過程,看看能發(fā)現(xiàn)什么。
            ??? 首先,對源代碼進(jìn)行編譯,是對各個(gè)cpp文件單獨(dú)進(jìn)行的。對于每一次編譯,如果排除在cpp文件里include別的cpp文件的情況(這是C++代碼編寫中極其錯(cuò)誤的寫法),那么編譯器僅僅知道當(dāng)前要編譯的那一個(gè)cpp文件,對其他的cpp文件的存在完全不知情。
            ??? 其次,每個(gè)cpp文件編譯后,產(chǎn)生的.o文件,要被一個(gè)鏈接器(link)所讀入,才能最終生成可執(zhí)行文件。
            ??? 好了,有了這些感性認(rèn)識之后,讓我們來看看C/C++程序是如何組織的。
            ?? ?
            ??? 首先要知道一些概念:
            ??? 編譯:編譯器對源代碼進(jìn)行編譯,是將以文本形式存在的源代碼翻譯為機(jī)器語言形式的目標(biāo)文件的過程。
            ??? 編譯單元:對于C++來說,每一個(gè)cpp文件就是一個(gè)編譯單元。從之前的編譯過程的演示可以看出,各個(gè)編譯單元之間是互相不可知的。
            ??? 目標(biāo)文件:由編譯所生成的文件,以機(jī)器碼的形式包含了編譯單元里所有的代碼和數(shù)據(jù),以及一些其他的信息。
            ?? ?
            ??? 下面我們具體看看編譯的過程。我們跳過語法分析等,直接來到目標(biāo)文件的生成。假設(shè)我們有一個(gè)1.cpp文件
            ??? ?int n = 1;

            ?? ?void f()
            ??? ?{
            ?? ??? ?++n;
            ?? ?}

            ??? 它編譯出來的目標(biāo)文件1.o就會有一個(gè)區(qū)域(假定名稱為2進(jìn)制段),包含了以上數(shù)據(jù)/函數(shù),其中有n, f,以文件偏移量的形式給出很可能就是:
            ?? ?偏移量?? ?內(nèi)容?? ?長度
            ?? ?0x000?? ?n?? ?4
            ?? ?0x004?? ?f ?? ???
            ??? 注意:這僅僅是猜測,不代表目標(biāo)文件的真實(shí)布局。目標(biāo)文件的各個(gè)數(shù)據(jù)不一定連續(xù),也不一定按照這個(gè)順序,當(dāng)然也不一定從0x000開始。
            ??? 現(xiàn)在我們看看從0x004開始f函數(shù)的內(nèi)容(在0x86平臺下的猜測):
            ?? ?0x004 inc DWORD PTR [0x000]
            ?? ?0x00? ret
            ??? 注意n++已經(jīng)被翻譯為:inc DWORD PTR [0x000],也就是把本單元0x000位置上的一個(gè)DWORD(4字節(jié))加1。
            ?? ?
            ??? 下面如果有另一個(gè)2.cpp,如下
            ?? ?extern int n;
            ?? ?void g()
            ?? ?{
            ?? ??? ?++n;
            ?? ?}
            ??? 那么它的目標(biāo)文件2.o的2進(jìn)制段就應(yīng)該是
            ?? ?偏移量?? ?內(nèi)容?? ?長度
            ?? ?0x000?? ?g ?? ???
            ??? 為什么這里沒有n的空間(也就是n的定義),因?yàn)閚被聲明為extern,表明n的定義在別的編譯單元里。別忘了編譯的時(shí)候是不可能知道別的編譯單元的情況的,故編譯器不知道n究竟在何處,所以這個(gè)時(shí)候g的二進(jìn)制代碼里沒有辦法填寫inc DWORD PTR [???]中的???部分。怎么辦呢?這個(gè)工作就只能交給后來的鏈接器去處理。為了讓鏈接器知道哪些地方的地址是沒有填好的,所以目標(biāo)文件還要有一個(gè)“未解決符號表”,也就是unresolved symbol table. 同樣,提供n的定義的目標(biāo)文件(也就是1.o)也要提供一個(gè)“導(dǎo)出符號表”,export symbol table, 來告訴鏈接器自己可以提供哪些地址。
            ??? 讓我們理一下思路:現(xiàn)在我們知道,每一個(gè)目標(biāo)文件,除了擁有自己的數(shù)據(jù)和二進(jìn)制代碼之外,還要至少提供2個(gè)表:未解決符號表和導(dǎo)出符號表,分別告訴鏈接器自己需要什么和能夠提供什么。下面的問題是,如何在2個(gè)表之間建立對應(yīng)關(guān)系。這里就有一個(gè)新的概念:符號。在C/C++中,每一個(gè)變量和函數(shù)都有自己的符號。例如變量n的符號就是“n”。函數(shù)的符號要更加復(fù)雜,它需要結(jié)合函數(shù)名及其參數(shù)和調(diào)用慣例等,得到一個(gè)唯一的字符串。f的符號可能就是"_f"(根據(jù)不同編譯器可以有變化)。
            ??? 所以,1.o的導(dǎo)出符號表就是
            ?? ?符號?? ?地址
            ?? ?n?? ?0x000
            ?? ?_f?? ?0x004
            ??? 而未解決符號表為空
            ??? 2.o的導(dǎo)出符號表為
            ?? ?符號?? ?地址
            ?? ?_g?? ?0x000
            ??? 未解決符號表為
            ?? ?符號?? ?地址?? ?
            ?? ?n?? ?0x001?? ?
            ??? 這里0x001為從0x000開始的inc DWORD PTR [???]的二進(jìn)制編碼中存儲???的起始地址(這里假設(shè)inc的機(jī)器碼的第2-5字節(jié)為要+1的絕對地址,需要知道確切情況可查手冊)。這個(gè)表告訴鏈接器,在本編譯單元0x001的位置上有一個(gè)地址,該地址值不明,但是具有符號n。
            ??? 鏈接的時(shí)候,鏈接器在2.o里發(fā)現(xiàn)了未解決符號n,那么在查找所有編譯單元的時(shí)候,在1.o中發(fā)現(xiàn)了導(dǎo)出符號n,那么鏈接器就會將n的地址0x000填寫到2.o的0x001的位置上。
            ??? “打住”,可能你就會跳出來指責(zé)我了。如果這樣做得話,豈不是g的內(nèi)容就會變成inc DWORD PTR [0x000],按照之前的理解,這是將本單元的0x000地址的4字節(jié)加1,而不是將1.o的對應(yīng)位置加1。是的,因?yàn)槊總€(gè)編譯單元的地址都是從0開始的,所以最終拼接起來的時(shí)候地址會重復(fù)。所以鏈接器會在拼接的時(shí)候?qū)Ω鱾€(gè)單元的地址進(jìn)行調(diào)整。這個(gè)例子中,假設(shè)2.o的0x00000000地址被定位在可執(zhí)行文件的0x00001000上,而1.o的0x00000000地址被定位在可執(zhí)行文件的0x00002000上,那么實(shí)際上對鏈接器來說,1.o的導(dǎo)出符號表其實(shí)
            ?? ?符號?? ?地址
            ?? ?n?? ?0x000 + 0x2000
            ?? ?_f?? ?0x004 + 0x2000
            ??? 而未解決符號表為空
            ??? 2.o的導(dǎo)出符號表為
            ?? ?符號?? ?地址
            ?? ?_g?? ?0x000 + 0x1000
            ??? 未解決符號表為
            ?? ?符號?? ?地址?? ??? ??? ?
            ?? ?n?? ?0x001 + 0x1000
            所以最終g的代碼會變?yōu)閕nc DWORD PTR [0x000 + 0x2000]。
            ??? 最后還有一個(gè)漏洞,既然最后n的地址變?yōu)?x2000了,那么以前f的代碼inc DWORD PTR [0x000]就是錯(cuò)誤的了。所以目標(biāo)文件為此還要提供一個(gè)表,叫做地址重定向表address redirect table。
            ??? 對于1.o來說,它的重定向表為
            ?? ?地址
            ?? ?0x005
            ??? 這個(gè)表不需要符號,當(dāng)鏈接器處理這個(gè)表的時(shí)候,發(fā)現(xiàn)地址為0x005的位置上有一個(gè)地址需要重定向,那么直接在以0x005開始的4個(gè)字節(jié)上加上0x2000就可以了。
            ??? 讓我們總結(jié)一下:編譯器把一個(gè)cpp編譯為目標(biāo)文件的時(shí)候,除了要在目標(biāo)文件里寫入cpp里包含的數(shù)據(jù)和代碼,還要至少提供3個(gè)表:未解決符號表,導(dǎo)出符號表和地址重定向表。
            ??? 未解決符號表提供了所有在該編譯單元里引用但是定義并不在本編譯單元里的符號及其出現(xiàn)的地址。
            ??? 導(dǎo)出符號表提供了本編譯單元具有定義,并且愿意提供給其他編譯單元使用的符號及其地址。
            ??? 地址重定向表提供了本編譯單元所有對自身地址的引用的記錄。
            ??? 鏈接器進(jìn)行鏈接的時(shí)候,首先決定各個(gè)目標(biāo)文件在最終可執(zhí)行文件里的位置。然后訪問所有目標(biāo)文件的地址重定向表,對其中記錄的地址進(jìn)行重定向(即加上該編譯單元實(shí)際在可執(zhí)行文件里的起始地址)。然后遍歷所有目標(biāo)文件的未解決符號表,并且在所有的導(dǎo)出符號表里查找匹配的符號,并在未解決符號表中所記錄的位置上填寫實(shí)際的地址(也要加上擁有該符號定義的編譯單元實(shí)際在可執(zhí)行文件里的起始地址)。最后把所有的目標(biāo)文件的內(nèi)容寫在各自的位置上,再作一些別的工作,一個(gè)可執(zhí)行文件就出爐了。
            ??? 最終link 1.o 2.o .... 所生成的可執(zhí)行文件大概是
            ?? ?0x00000000? ????(別的一些信息)
            ?? ?....
            ?? ?0x00001000? inc DWORD PTR [0x00002000]???????? ??? ?//這里是2.o的開始,也就是g的定義
            ?? ?0x00001005? ret???????????????????????????? ??? ?//假設(shè)inc為5個(gè)字節(jié),這里是g的結(jié)尾
            ?? ?....
            ?? ?0x00002000? 0x00000001????????????????????? ??? ?//這里是1.o的開始,也是n的定義(初始化為1)
            ?? ?0x00002004? inc DWORD PTR [0x00002000]?? ? ?? ?//這里是f的開始
            ?? ?0x00002009? ret???????????????????????????? ??? ?//假設(shè)inc為5個(gè)字節(jié),這里是f的結(jié)尾
            ?? ?...
            ?? ?...
            ??? 實(shí)際鏈接的時(shí)候更為復(fù)雜,因?yàn)閷?shí)際的目標(biāo)文件里把數(shù)據(jù)/代碼分為好幾個(gè)區(qū),重定向等要按區(qū)進(jìn)行,但原理是一樣的。


            ?? ?
            ??? 現(xiàn)在我們可以來看看幾個(gè)經(jīng)典的鏈接錯(cuò)誤了:
            ?? ?unresolved external link..
            ?? ?這個(gè)很顯然,是鏈接器發(fā)現(xiàn)一個(gè)未解決符號,但是在導(dǎo)出符號表里沒有找到對應(yīng)的項(xiàng)。
            ?? ?解決方案么,當(dāng)然就是在某個(gè)編譯單元里提供這個(gè)符號的定義就行了。(注意,這個(gè)符號可以是一個(gè)變量,也可以是一個(gè)函數(shù)),也可以看看是不是有什么該鏈接的文件沒有鏈接
            ?? ?duplicated external simbols...
            ?? ?這個(gè)則是導(dǎo)出符號表里出現(xiàn)了重復(fù)項(xiàng),因此鏈接器無法確定應(yīng)該使用哪一個(gè)。這可能是使用了重復(fù)的名稱,也可能有別的原因。


            ??? 我們再來看看C/C++語言里針對這一些而提供的特性:
            ?? ?extern:這是告訴編譯器,這個(gè)符號在別的編譯單元里定義,也就是要把這個(gè)符號放到未解決符號表里去。(外部鏈接)
            ?? ?
            ?? ?static:如果該關(guān)鍵字位于全局函數(shù)或者變量的聲明的前面,表明該編譯單元不導(dǎo)出這個(gè)函數(shù)/變量的符號。因此無法在別的編譯單元里使用。(內(nèi)部鏈接)。如果是static局部變量,則該變量的存儲方式和全局變量一樣,但是仍然不導(dǎo)出符號。
            ?? ?
            ?? ?默認(rèn)鏈接屬性:對于函數(shù)和變量,模認(rèn)外部鏈接,對于const變量,默認(rèn)內(nèi)部鏈接。(可以通過添加extern和static改變鏈接屬性)

            ?? ?外部鏈接的利弊:外部鏈接的符號,可以在整個(gè)程序范圍內(nèi)使用(因?yàn)閷?dǎo)出了符號)。但是同時(shí)要求其他的編譯單元不能導(dǎo)出相同的符號(不然就是duplicated external simbols)

            ?? ?內(nèi)部鏈接的利弊:內(nèi)部鏈接的符號,不能在別的編譯單元內(nèi)使用。但是不同的編譯單元可以擁有同樣名稱的內(nèi)部鏈接符號。

            ?? ?為什么頭文件里一般只可以有聲明不能有定義:頭文件可以被多個(gè)編譯單元包含,如果頭文件里有定義,那么每個(gè)包含這個(gè)頭文件的編譯單元就都會對同一個(gè)符號進(jìn)行定義,如果該符號為外部鏈接,則會導(dǎo)致duplicated external simbols。因此如果頭文件里要定義,必須保證定義的符號只能具有內(nèi)部鏈接。

            ?? ?為什么常量默認(rèn)為內(nèi)部鏈接,而變量不是:
            ?? ??? ?這就是為了能夠在頭文件里如const int n = 0這樣的定義常量。由于常量是只讀的,因此即使每個(gè)編譯單元都擁有一份定義也沒有關(guān)系。如果一個(gè)定義于頭文件里的變量擁有內(nèi)部鏈接,那么如果出現(xiàn)多個(gè)編譯單元都定義該變量,則其中一個(gè)編譯單元對該變量進(jìn)行修改,不會影響其他單元的同一變量,會產(chǎn)生意想不到的后果。

            ?? ?為什么函數(shù)默認(rèn)是外部鏈接:
            ?? ??? ?雖然函數(shù)是只讀的,但是和變量不同,函數(shù)在代碼編寫的時(shí)候非常容易變化,如果函數(shù)默認(rèn)具有內(nèi)部鏈接,則人們會傾向于把函數(shù)定義在頭文件里,那么一旦函數(shù)被修改,所有包含了該頭文件的編譯單元都要被重新編譯。另外,函數(shù)里定義的靜態(tài)局部變量也將被定義在頭文件里。

            ?? ?為什么類的靜態(tài)變量不可以就地初始化:所謂就地初始化就是類似于這樣的情況:
            ?? ??? ?class A
            ?? ??? ?{
            ?? ??? ??? ?static char msg[] = "aha";
            ?? ??? ?};
            不允許這樣做得原因是,由于class的聲明通常是在頭文件里,如果允許這樣做,其實(shí)就相當(dāng)于在頭文件里定義了一個(gè)非const變量。

            ?? ?在C++里,頭文件定義一個(gè)const對象會怎么樣:
            ?? ??? ?一般不會怎么樣,這個(gè)和C里的在頭文件里定義const int一樣,每一個(gè)包含了這個(gè)頭文件的編譯單元都會定義這個(gè)對象。但由于該對象是const的,所以沒什么影響。但是:有2種情況可能破壞這個(gè)局面:
            ?? ??? ?1。如果涉及到對這個(gè)const對象取地址并且依賴于這個(gè)地址的唯一性,那么在不同的編譯單元里,取到的地址可以不同。(但一般很少這么做)
            ?? ??? ?2。如果這個(gè)對象具有mutable的變量,某個(gè)編譯單元對其進(jìn)行修改,則同樣不會影響到別的編譯單元。

            ?? ?為什么類的靜態(tài)常量也不可以就地初始化:
            ?? ??? ?因?yàn)檫@相當(dāng)于在頭文件里定義了const對象。作為例外,int/char等可以進(jìn)行就地初始化,是因?yàn)檫@些變量可以直接被優(yōu)化為立即數(shù),就和宏一樣。

            ?? ?內(nèi)聯(lián)函數(shù):
            ?? ??? ?C++里的內(nèi)聯(lián)函數(shù)由于類似于一個(gè)宏,因此不存在鏈接屬性問題。

            ?? ?為什么公共使用的內(nèi)聯(lián)函數(shù)要定義于頭文件里:
            ?? ??? ?因?yàn)榫幾g時(shí)編譯單元之間互相不知道,如果內(nèi)聯(lián)函數(shù)被定義于.cpp文件中,編譯其他使用該函數(shù)的編譯單元的時(shí)候沒有辦法找到函數(shù)的定義,因此無法對函數(shù)進(jìn)行展開。所以說如果內(nèi)聯(lián)函數(shù)定義于.cpp文件里,那么就只有這個(gè)cpp文件可以是用這個(gè)函數(shù)。

            ?? ?頭文件里內(nèi)聯(lián)函數(shù)被拒絕會怎樣:
            ?? ??? ?如果定義于頭文件里的內(nèi)聯(lián)函數(shù)被拒絕,那么編譯器會自動在每個(gè)包含了該頭文件的編譯單元里定義這個(gè)函數(shù)并且不導(dǎo)出符號。

            ?? ?如果被拒絕的內(nèi)聯(lián)函數(shù)里定義了靜態(tài)局部變量,這個(gè)變量會被定義于何處:
            ?? ??? ?早期的編譯器會在每個(gè)編譯單元里定義一個(gè),并因此產(chǎn)生錯(cuò)誤的結(jié)果,較新的編譯器會解決這個(gè)問題,手段未知。

            ?? ?為什么export關(guān)鍵字沒人實(shí)現(xiàn):
            ?? ??? ?export要求編譯器跨編譯單元查找函數(shù)定義,使得編譯器實(shí)現(xiàn)非常困難。

            Feedback

            # re: 詳解compile & link  回復(fù)  更多評論   

            2007-07-07 10:54 by zw
            高手啊,學(xué)習(xí)了

            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            成人a毛片久久免费播放| 久久人妻少妇嫩草AV无码专区| 久久AV高潮AV无码AV| 国产成人精品久久亚洲| av午夜福利一片免费看久久| 婷婷五月深深久久精品| 久久精品国产日本波多野结衣| 欧美日韩精品久久久久| 狠狠色丁香婷婷综合久久来来去| 久久精品国产精品青草| 亚洲国产精久久久久久久| 99re这里只有精品热久久| 日本久久久精品中文字幕| 精品一区二区久久| 91精品国产91久久久久久| 国产精品狼人久久久久影院| 久久久91人妻无码精品蜜桃HD| 久久99国产精品成人欧美| 亚洲а∨天堂久久精品| 亚洲精品午夜国产VA久久成人| 99久久er这里只有精品18| 18岁日韩内射颜射午夜久久成人 | 中文字幕乱码人妻无码久久| 无码精品久久久天天影视| 国产精品美女久久久m| 久久精品国产半推半就| 色综合久久天天综线观看| 国内精品人妻无码久久久影院导航| 久久婷婷激情综合色综合俺也去| 久久精品成人免费看| 中文字幕久久精品| 久久精品中文闷骚内射| 蜜桃麻豆www久久国产精品| 亚洲国产精品成人久久| 久久激情亚洲精品无码?V| 久久久久久久波多野结衣高潮| 久久精品视频免费| 久久精品国产免费观看三人同眠| 久久99热国产这有精品| 国产成人久久精品一区二区三区 | 国产精品嫩草影院久久|