linux動態庫的種種要點
linux下使用動態庫,基本用起來還是非常easy。但假設我們的程序中大量使用動態庫來實現各種框架/插件,那麽就會遇到一些坑,掌握這些坑才有利於程序更穩健地執行。
本篇先談談動態庫符號方面的問題。
測試代碼能夠在github上找到
符號查找
一個應用程序test
會鏈接一個動態庫libdy.so
,假設一個符號。比如函數callfn
定義於libdy.so中,test要使用該函數,簡單地聲明就可以:
// dy.cpp libdy.so void callfn() { ... } // main.cpp test extern void callfn(); callfn();
在鏈接test的時候,鏈接器會統一進行檢查。
相同,在libdy.so中有相同的規則,它能夠使用一個外部的符號,在它被鏈接/加載進一個可運行程序時才會進行符號存在與否的檢查。這個符號甚至能夠定義在test中,形成一種雙向依賴,或定義在其它動態庫中:
// dy.cpp libdy.so extern void mfunc(); mfunc(); // main.cpp test void mfunc() { ... }
在生成libdy.so時mfunc
能夠找不到,此時mfunc
為沒有定義:
$ nm libdy.so | grep mfun U _Z5mfuncv
但在libdy.so被鏈接進test時則會進行檢查,試著把mfunc
./libdy.so: undefined reference to `mfunc()'
相同。假設我們動態加載libdy.so,此時當然能夠鏈接通過,可是在加載時相同得到找不到符號的錯誤:
#ifdef DY_LOAD void *dp = dlopen("./libdy.so", RTLD_LAZY); typedef void (*callfn)(); callfn f = (callfn) dlsym(dp, "callfn"); f(); dlclose(dp); #else callfn(); #endif
得到錯誤:
./test: symbol lookup error: ./libdy.so: undefined symbol: _Z5mfuncv
結論:基於以上,我們知道,假設一個動態庫依賴了一些外部符號,這些外部符號能夠位於其它動態庫甚至應用程序中。
我們能夠再鏈接這個動態庫的時候就把依賴的其它庫也鏈接上,或者推遲到鏈接應用程序時再鏈接。而動態載入的庫,則要保證在載入該庫時,進程中載入的其它動態庫裏已經存在該符號。
比如。通過LD_PRELOAD
環境變量能夠讓一個進程先載入指定的動態庫,上面那個動態載入啟動失敗的樣例,能夠通過預先載入包括mfunc
符號的動態庫解決:
$ LD_PRELOAD=libmfun.so ./test ...
可是假設這個符號存在於可運行程序中則不行:
$ nm test | grep mfunc 0000000000400a00 T _Z5mfuncv $ nm test | grep mfunc 0000000000400a00 T _Z5mfuncv $ ./test ... ./test: symbol lookup error: ./libdy.so: undefined symbol: _Z5mfuncv
符號覆蓋
前面主要講的是符號缺少的情況。假設同一個符號存在多分。則更能引發問題。這裏談到的符號都是全局符號。一個進程中某個全局符號始終是全局唯一的。為了保證這一點。在鏈接或動態加載動態庫時。就會出現忽略反復符號的情況。
這裏就不提同一個鏈接單位(如可運行程序、動態庫)裏符號反復的問題了
函數
當動態庫和libdy.so可運行程序test中包括同名的函數時會如何?依據是否動態載入情況還有所不同。
當直接鏈接動態庫時,libdy.so和test都會鏈接包括func
函數的fun.o。為了區分。我把func
依照條件編譯得到不同的版本號:
// fun.cpp #ifdef V2 extern "C" void func() { printf("func v2\n"); } #else extern "C" void func() { printf("func v1\n"); } #endif // Makefile test: libdy obj.o mainfn g++ -g -Wall -c fun.cpp -o fun.o # 編譯為fun.o g++ -g -Wall -c main.cpp #-DDY_LOAD g++ -g -Wall -o test main.o obj.o fun.o -ldl mfun.o -ldy -L. libdy: obj g++ -Wall -fPIC -c fun.cpp -DV2 -o fun-dy.o # 定義V2宏,編譯為fun-dy.o g++ -Wall -fPIC -shared -o libdy.so dy.cpp -g obj.o fun-dy.o
這樣,test中的func
就會輸出func v1
;libdy.so中的func
就會輸出func v2
。
test和libdy.o確實都有func
符號:
$ nm libdy.so | grep func 0000000000000a60 T func $nm test | grep func 0000000000400a80 T func
在test和libdy.so中都會調用func
函數:
// main.cpp test int main(int argc, char **argv) { func(); ... callfn(); // 調用libdy.so中的函數 ... } // dy.cpp libdy.so extern "C" void callfn() { ... printf("callfn\n"); func(); ... }
執行後發現。都調用的是同一個func
:
$ ./test ... func v1 ... callfn func v1
結論,直接鏈接動態庫時,整個程序執行的時候符號會發生覆蓋,僅僅有一個符號被使用。在實踐中,假設程序和鏈接的動態庫都依賴了一個靜態庫,而後他們鏈接的這個靜態庫版本號不同,則非常有可能由於符號發生了覆蓋而導致問題。(靜態庫同普通的.o性質一樣,參考淺析靜態庫鏈接原理)
更復雜的情況中。多個動態庫和程序都有同樣的符號。情況也是一樣。會發生符號覆蓋。假設程序裏沒有這個符號,而多個動態庫裏有同樣的符號,也會覆蓋。
可是對於動態加載的情況則不同。相同的libdy.so我們在test中不鏈接,而是動態加載:
int main(int argc, char **argv) { func(); #ifdef DY_LOAD void *dp = dlopen("./libdy.so", RTLD_LAZY); typedef void (*callfn)(); callfn f = (callfn) dlsym(dp, "callfn"); f(); func(); dlclose(dp); #else callfn(); #endif return 0; }
執行得到:
$ ./test func v1 ... callfn func v2 func v1
都正確地調用到各自鏈接的func
。
結論。實踐中,動態加載的動態庫通常會作為插件使用,那麽其同程序鏈接不同版本號的靜態庫(同樣符號不同實現),是沒有問題的。
變量
變量本質上也是符號(symbol),但其處理規則和函數還有點不一樣(是不是有點想吐槽了)。
// object.h class Object { public: Object() { #ifdef DF s = malloc(32); printf("s addr %p\n", s); #endif printf("ctor %p\n", this); } ~Object() { printf("dtor %p\n", this); #ifdef DF printf("s addr %p\n", s); free(s); #endif } void *s; }; extern Object g_obj;
我們的程序test和動態庫libdy.so都會鏈接object.o。
首先測試test鏈接libdy.so,test和libdy.so中都會有g_obj
這個符號:
// B g_obj 表示g_obj位於BSS段,未初始化段 $ nm test | grep g_obj 0000000000400a14 t _GLOBAL__I_g_obj 00000000006012c8 B g_obj $ nm libdy.so | grep g_obj 000000000000097c t _GLOBAL__I_g_obj 0000000000200f30 B g_obj
執行:
$ ./test ctor 0x6012c8 ctor 0x6012c8 ... dtor 0x6012c8 dtor 0x6012c8
g_obj
被構造了兩次,但地址一樣。全局變量僅僅有一個實例,似乎在情理之中。
動態加載libdy.so,變量地址還是同樣的:
$ ./test ctor 0x6012a8 ... ctor 0x6012a8 ... dtor 0x6012a8 dtor 0x6012a8
結論,不同於函數,全局變量符號反復時。不論動態庫是動態加載還是直接鏈接,變量始終僅僅有一個。
但詭異的情況是,對象被構造和析構了兩次。構造兩次倒無所謂,浪費點空間,可是析構兩次就有問題。由於析構時都操作的是同一個對象。那麽假設這個對象內部有分配的內存,那就會對這塊內存造成double free,由於指針同樣。打開DF
宏實驗下:
$ ./test s addr 0x20de010 ctor 0x6012b8 s addr 0x20de040 ctor 0x6012b8 ... dtor 0x6012b8 s addr 0x20de040 dtor 0x6012b8 s addr 0x20de040
由於析構的兩次都是同一個對象,所以其成員s
指向的內存被釋放了兩次。從而產生了double free,讓程序coredump了。
總結。全局變量符號反復時。始終會僅僅使用一個,而且會被初始化/釋放兩次,是一種較危急的情況,應當避免在使用動態庫的過程中使用全局變量。
完
linux動態庫的種種要點