舉例講解C語言鏈接器的符號解析機制
1. 符號分類
(1)全局符號:非靜態(tài)全局變量,非靜態(tài)函數(shù)
(2)外部符號:定義于其它模塊,而被本模塊引用的全局變量和函數(shù)
(3)本地符號:靜態(tài)變量(包括全局和局部),靜態(tài)函數(shù)
對于靜態(tài)局部變量,編譯器會為其生成唯一的名字。如x.fun1,x.fun2。本地符號對鏈接器來說是不可見的。
2. 符號決議
當(dāng)編譯器遇到一個不是本模塊定義的符號時,會假設(shè)該函數(shù)由其它模塊定義,并生成一個鏈接器符號表條目,交由鏈接器處理。如果鏈接器在它的任何輸入模塊都沒有找到該符號,會給出一個類似undefined reference to 'xxx'的鏈接錯誤。而如果鏈接器在輸入模塊中找到了一個以上的外部符號定義,這個時候就需要鏈接器進行符號決議,鏈接器對多個外部符號定義可能并不報錯甚至警告,而是按照它的規(guī)則去選擇其中一個符號定義。
鏈接器將各個模塊輸出的全局符號,分類為強符號和弱符號:
(1)強符號:函數(shù)和已初始化的全局變量
(2)弱符號:為初始化全局變量
根據(jù)強弱符號的定義,鏈接器按照下面的規(guī)則處理多重定義的符號:
規(guī)則1:不允許有多個強符號定義
規(guī)則2:如果有一個強符號和多個弱符號,那么選擇強符號
規(guī)則3:如果有多個弱符號,那么從這些弱符號中選擇sizeof大的那個,如果大小相同,則選擇先鏈接的那個
上面的規(guī)則是很多鏈接錯誤的根源,因為編譯器在決議時可能默默地替你作出了決定,你并不知曉。根據(jù)上面的規(guī)則,可以引出下面幾個經(jīng)典例子:
例1:
// in lib1.c int x; void f() { x = 1235; } // in main1.c #include<stdio.h> void f(void); int x = 1234; int main(void) { f(); printf("x=%d\n", x); return 0; }
上面的代碼中,main函數(shù)printf輸出: x=1235。因為鏈接器通過規(guī)則2決議符號x的定義為main.c中的強符號定義,而lib.c的作者并不知情,他對x的使用和修改影響到了main.c。這種交互修改,相互影響將會很復(fù)雜,因為大家都以為自己在做對的事情,在用對的變量。而整個決議過程,鏈接器悄無聲息地完成了。
例2:
// in lib2.c double x; void f() { x = -0.0; } // in main2.c #include<stdio.h> void f(void); int x = 1234; int y = 1235; int main() { f(); printf("x=0x%x y=0x%x \n", x, y); return 0; }
這種情況下,程序得到輸出: x=0x0 y=0x80000000,而鏈接器(gcc ld)也終于給出一條警告:
ld: warning: tentative definition of '_x' with size 8 from 'obj/Debug/lib2.o' is being replaced by real definition of smaller size 4 from 'obj/Debug/main2.o'
鏈接器決議的是符號地址,而相鄰的全局變量可能在.data段中的內(nèi)存地址也相鄰,因此也就引發(fā)了更復(fù)雜的問題。這一點和棧溢出很像,但是比棧溢出更復(fù)雜,因為問題出在多個模塊之間,而不是在一個函數(shù)內(nèi)部。
例3:
// in lib3.c struct { int a; int b; } x; void f() { x.a = 123; x.b = 456; printf("in f(): sizeof(x)=%d, (&x)=0x%08x\n", sizeof(x), &x); } // in main3.c #include<stdio.h> void f(void); int x; int y; int main() { f(); printf("in main(): sizeof(x)=%d, (&x)=0x%08x, (&x)=0x%08x, x=%d,y=%d \n", sizeof(x), &x, &y, x, y); return 0; }
程序輸出:
in f(): sizeof(x)=8, (&x)=0x02489018 in main(): sizeof(x)=4, (&x)=0x02489018, (&y)=0x02489020, x=123,y=0
始終記住,外部符號決議的是地址,因此無論lib3.c和main3.c中,符號x地址都是唯一的,無論其被定義了幾次。其次sizeof是編譯器決議,與鏈接無關(guān),編譯器只看得到本模塊的定義或聲明。最后,由于符號x決議到lib3.c中的x,其size是8,因此main3.c中的y的地址比x大8,這是由鏈接器將lib3.o和main3.o合并后填入可執(zhí)行文件的.data段的。因此y是無關(guān)變量,被初始化為0,注意和例2的區(qū)別。
3. 總結(jié)
由于符號決議容易引發(fā)的種種問題,我們在寫C的時候應(yīng)注意:
盡量用static屬性隱藏變量和函數(shù)在模塊內(nèi)的聲明,就像在C++中盡量用private保護類私有成員一樣。
少定義弱符號,盡量初始化全局變量,這樣鏈接器會根據(jù)規(guī)則1給出多個符號定義的錯誤。
為鏈接器設(shè)置必要選項,如gcc的 -fno-common,這樣在遇到多重符號定義時,鏈接器會給出警告。
4. C++的符號決議
C++并不支持強弱符號同時存在,所有符號都只能有一個定義(函數(shù)重載通過改寫函數(shù)符號來確保其唯一),因此在很大程度上避免了C中的鏈接器困擾。
相關(guān)文章
Qt+QListWidget實現(xiàn)氣泡聊天界面(附源碼)
由于最近的項目需要,做了些相關(guān)IM的工作。所以聊天框也是必不可少的一部分。本文以QListWidget+QPainter繪制的Item做了一個Demo。該Demo只是做一個示例,感興趣的可以了解一下2022-12-12c++ lambda捕獲this 導(dǎo)致多線程下類釋放后還在使用的錯誤問題
Lambda表達式是現(xiàn)代C++的一個語法糖,挺好用的。但是如果使用不當(dāng),會導(dǎo)致內(nèi)存泄露或潛在的崩潰問題,這里總結(jié)下c++ lambda捕獲this 導(dǎo)致多線程下類釋放后還在使用的錯誤問題,感興趣的朋友一起看看吧2023-02-02結(jié)構(gòu)體對齊的規(guī)則詳解及C++代碼驗證
在c語言的結(jié)構(gòu)體里面一般會按照某種規(guī)則去進行字節(jié)對齊。本文就來介紹一下如何實現(xiàn),具有一定的參考價值,感興趣的可以了解下2021-08-08C語言實現(xiàn)學(xué)生信息管理系統(tǒng)開發(fā)
這篇文章主要為大家詳細介紹了C語言實現(xiàn)學(xué)生信息管理系統(tǒng)開發(fā),文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下2022-08-08