linux gcc鏈接的可執行文件缺少stat64的靜態定義

一個linux stat64調用應該最終調用xstat64，並生成一個靜態版本的stat64，該版本會隨調用一起傳遞一個版本。linux gcc鏈接的可執行文件缺少stat64的靜態定義

我們正在看到一個條件，其中調用stat64的C鏈接（gcc）版本鏈接到較舊版本的（C++鏈接）共享庫（libdb2.so.1，使用stat64，但isn不應該提供它），而不是以stat64調用的「適當」靜態版本結束。 ++的應用程序中的C具有我們所期望的：

00000000004007c8 <[email protected]>: 
    4007c8: jmpq *1051250(%rip)  # 501240 <_GLOBAL_OFFSET_TABLE_+0x20> 
    4007ce: pushq $0x1 
    4007d3: jmpq 4007a8 <_init+0x18> 

0000000000400ac0 <stat64>: 
    400ac0: push %rbp 
    400ac1: mov %rsp,%rbp 
    400ac4: sub $0x10,%rsp 
    400ac8: mov %rdi,0xfffffffffffffff8(%rbp) 
    400acc: mov %rsi,0xfffffffffffffff0(%rbp) 
    400ad0: mov 0xfffffffffffffff0(%rbp),%rdx 
    400ad4: mov 0xfffffffffffffff8(%rbp),%rsi 
    400ad8: mov $0x1,%edi 
    400add: callq 4007c8 <[email protected]> 
    400ae2: leaveq 
    400ae3: retq

而GCC鏈接的代碼（也鏈接到我們的libdb2共享庫）結束了一個全球參考stat64中，而不是它是假設的「靜態」版本有：

0000000000400618 <[email protected]>: 
    400618: jmpq *1050146(%rip)  # 500c40 <_GLOBAL_OFFSET_TABLE_+0x20> 
    40061e: pushq $0x1 
    400623: jmpq 4005f8 <_init+0x18>

相同的代碼，也當用gcc的時候不要鏈接到我們libdb2庫鏈接，最終與預期的「靜態」 stat64中功能：

0000000000400550 <[email protected]>: 
    400550: jmpq *1050170(%rip)  # 500b90 <_GLOBAL_OFFSET_TABLE_+0x20> 
    400556: pushq $0x1 
    40055b: jmpq 400530 <_init+0x18> 

00000000004007b0 <stat64>: 
    4007b0: mov %rsi,%rdx 
    4007b3: mov %rdi,%rsi 
    4007b6: mov $0x1,%edi 
    4007bb: jmpq 400550 <[email protected]>

編輯：更多的我nfo從鏈接器映射獲得（-Wl， - print-map）

當gcc鏈接的exe文件沒有鏈接到我們的（libdb2）共享庫時，我們看到它從libc_nonshared.a獲取它的stat64文件：

/usr/lib64/libc_nonshared.a(stat64.oS) 
           /home/hotellnx94/peeterj/tmp/cc2f7ETx.o (stat64) 
... 

.plt   0x0000000000400530  0x70 
*(.plt) 
.plt   0x0000000000400530  0x70 /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/crt1.o 
       0x0000000000400540    [email protected]@GLIBC_2.2.5 
       0x0000000000400550    [email protected]@GLIBC_2.2.5 
       0x0000000000400560    [email protected]@GLIBC_2.2.5 
       0x0000000000400570    [email protected]@GLIBC_2.2.5 
       0x0000000000400580    [email protected]@GLIBC_2.2.5 
       0x0000000000400590    [email protected]@GLIBC_2.2.5 

.text   0x00000000004007b0  0x10 /usr/lib64/libc_nonshared.a(stat64.oS) 
       0x00000000004007b0    stat64

然而，一旦我們鏈接到我們的共享庫（libdb2），這些符號是從crt1.o撿起來代替lib_nonshared.a：

.plt   0x00000000004005f8  0x70 
*(.plt) 
.plt   0x00000000004005f8  0x70 /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/crt1.o 
       0x0000000000400608    [email protected]@GLIBC_2.2.5 
       0x0000000000400618    stat64 
       0x0000000000400628    [email protected]@GLIBC_2.2.5 
       0x0000000000400638    [email protected]@GLIBC_2.2.5 
       0x0000000000400648    [email protected]@GLIBC_2.2.5 
       0x0000000000400658    [email protected]@GLIBC_2.2.5

什麼我們也不會做（或將有一直在做，因爲我們沒有看到這在我們的圖書館的新版本中），這會導致lib_nonshared.a不再b e消費者鏈接到我們的圖書館後共享嗎？

來源

2013-05-10 Peeter Joot

事實證明，這是由於一個英特爾編譯器錯誤已修復。當我們開始使用具有修補程序的編譯器版本時，由於新版本的intel編譯器（生成有問題的共享庫），因此我們遇到了二進制兼容性問題，因此無法正確導出此stat64符號。

來源

2013-10-29 17:55:59

linux gcc鏈接的可執行文件缺少stat64的靜態定義

回答

相關問題