linux gcc связанный исполняемый файл отсутствует статическое определение stat64

Question

Ожидается, что вызов linux stat64 закончится вызовом xstat64 со статической версией stat64, которая передает версию вместе с вызовом.

Мы видим условие, в котором C-код (gcc), вызывающий stat64, связан с более старой версией (C++ связанной) общей библиотеки (libdb2.so.1, которая использует stat64, но isn 't должен обеспечить его), не заканчивается «правильной» статической версией этого вызова stat64. C++ связано приложение имеет то, что мы ожидаем:

00000000004007c8 <__xstat64@plt>: 
    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 <__xstat64@plt> 
    400ae2: leaveq 
    400ae3: retq 

, тогда как GCC связанный код (который также ссылки на наш libdb2 общей Lib) заканчивается глобальной ссылкой на stat64 вместо «статической» версии, что это предполагают иметь:

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

Тот же самый код, а также при связывании с GCC, когда не связана с нашей библиотекой libdb2, заканчивается ожидаемым «статической» stat64 функции:

0000000000400550 <__xstat64@plt>: 
    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 <__xstat64@plt> 

EDIT: больше я nfo, полученное из компоновщика (-Wl, - print-map)

Когда gcc-связанный exe не ссылается на наш (libdb2) общий lib, мы видим, что он получает stat64 из libc_nonshared.a:

/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    __libc_start_main@@GLIBC_2.2.5 
       0x0000000000400550    __xstat64@@GLIBC_2.2.5 
       0x0000000000400560    printf@@GLIBC_2.2.5 
       0x0000000000400570    memset@@GLIBC_2.2.5 
       0x0000000000400580    strerror@@GLIBC_2.2.5 
       0x0000000000400590    __errno_location@@GLIBC_2.2.5 

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

тогда, когда мы ссылаемся на нашей общей Lib (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    __libc_start_main@@GLIBC_2.2.5 
       0x0000000000400618    stat64 
       0x0000000000400628    printf@@GLIBC_2.2.5 
       0x0000000000400638    memset@@GLIBC_2.2.5 
       0x0000000000400648    strerror@@GLIBC_2.2.5 
       0x0000000000400658    __errno_location@@GLIBC_2.2.5 

что мы могли бы делать (или будет иметь так как мы не видим этого в новых версиях нашей библиотеки), что приведет к тому, что lib_nonshared.a больше не будет b e, если потребитель обращается к нашей библиотеке?

Answer 1

Оказалось, что это связано с ошибкой компилятора Intel, которая была исправлена. Когда мы начали использовать версию компилятора, у которой было исправление, мы столкнулись с проблемой двоичной совместимости, так как новая версия компилятора Intel (создание общей библиотеки) не правильно экспортировала этот символ stat64.