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消费者链接到我们的图书馆后共享吗?
答
事实证明,这是由于一个英特尔编译器错误已修复。当我们开始使用具有修补程序的编译器版本时,由于新版本的intel编译器(生成有问题的共享库),因此我们遇到了二进制兼容性问题,因此无法正确导出此stat64符号。