ELF重新定位 - 哪里来自这些符号？

在我的Debian x86 32位中，当我执行readelf -r /usr/lib/libstdc++.so.6 | grep的并行线程，我得到这样的输出：ELF重新定位 - 哪里来自这些符号？

000eceac 00006206 R_386_GLOB_DAT 00000000 pthread_cancel 
000ed058 00000807 R_386_JUMP_SLOT 00000000 pthread_cond_destroy 
000ed148 00001207 R_386_JUMP_SLOT 00000000 pthread_cond_signal 
000ed1e8 00001e07 R_386_JUMP_SLOT 00000000 pthread_key_create 
000ed320 00002a07 R_386_JUMP_SLOT 00000000 pthread_once 
000ed418 00003607 R_386_JUMP_SLOT 00000000 pthread_getspecific 
000ed42c 00003a07 R_386_JUMP_SLOT 00000000 pthread_mutex_unlock 
000ed4ec 00004607 R_386_JUMP_SLOT 00000000 pthread_create 
000ed54c 00004b07 R_386_JUMP_SLOT 00000000 pthread_equal 
000ed678 00005607 R_386_JUMP_SLOT 00000000 pthread_mutex_lock 
000ed71c 00006007 R_386_JUMP_SLOT 00000000 pthread_cond_wait 
000ed7b0 00006907 R_386_JUMP_SLOT 00000000 pthread_key_delete 
000ed8b4 00007307 R_386_JUMP_SLOT 00000000 pthread_cond_broadcast 
000ed8c0 00007507 R_386_JUMP_SLOT 00000000 pthread_detach 
000ed8f0 00007a07 R_386_JUMP_SLOT 00000000 pthread_setspecific 
000ed968 00007c07 R_386_JUMP_SLOT 00000000 pthread_join

然而

当我列出/usr/lib/libstdc++.so.6的libpthread的依赖性没有列出：

[email protected]:~$ ldd /usr/lib/libstdc++.so.6 
linux-gate.so.1 => (0xb77df000) 
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb76ad000) 
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7566000) 
/lib/ld-linux.so.2 (0xb77e0000) 
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7547000)

所以如何将这些依赖关系由动态加载程序解决？我在__gmon_start__中发现了一个类似的问题，粗略地说，这个符号的定义是什么？

来源

2012-10-02 JohnTortugo

为什么这些定义没有按” t出现在定义为依赖关系的库中？ – JohnTortugo

Linux中的pthread函数在libc中实现。

例如，一个系统上，我不得不用手：

objdump -T /lib/libc-2.11.1.so | grep pthread

给出

00000000000f64a0 g DF .text 0000000000000026 GLIBC_2.3.2 pthread_cond_signal 
0000000000126100 g DF .text 0000000000000026 (GLIBC_2.2.5) pthread_cond_signal 
00000000000f6be0 g DF .text 000000000000005a GLIBC_PRIVATE __libc_pthread_init 
00000000000f65f0 g DF .text 0000000000000026 GLIBC_2.2.5 pthread_mutex_lock 
00000000000f63e0 g DF .text 0000000000000026 GLIBC_2.2.5 pthread_condattr_init 
00000000000f6290 g DF .text 0000000000000026 GLIBC_2.2.5 pthread_attr_getschedparam 
...

来源

2012-10-02 03:49:37

要回答的问题的第二部分，__gmon_start__是 C运行时部，并在可执行文件为 gprof(1)风格的分析构建时使用。

在Ubuntu的GNU/Linux，相关定义可以在/usr/lib/gcrt1.o发现：

% nm /usr/lib/gcrt1.o| grep -C2 gmon_start 
00000000 R _IO_stdin_used 
00000000 D __data_start 
00000030 T __gmon_start__ 
     U __libc_csu_fini 
     U __libc_csu_init

对于正常编译运行，/usr/lib/crti.o提供了一个 '弱' 的定义：

% nm /usr/lib/crti.o| grep -C2 gmon_start 
      U _GLOBAL_OFFSET_TABLE_ 
      w __gmon_start__ 
00000000 T _fini 
00000000 T _init

来源

2012-10-02 12:19:02 jkoshy

为什么/usr/lib/crti.o在我执行ldd时未列出？ – JohnTortugo

'/ usr/lib/crti.o'是一个普通的可重定位的对象，而不是一个可动态加载的对象。您可以研究'cc -v'的输出以查看链接时如何使用该对象。 – jkoshy

是的。所以任何依赖不应该在编译时解决？您能否更具体地介绍cc -v，我的系统中的输出显然不包含与crti.o相关的任何内容，可能与问题相关的唯一内容是--enable-threads = posix。 – JohnTortugo

ELF重新定位 - 哪里来自这些符号？

回答

相关问题