1

In my Debian x86 32 Bits, when I do readelf -r /usr/lib/libstdc++.so.6 | grep pthread, I get this output:

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

however when I list the dependencies of /usr/lib/libstdc++.so.6 libpthread isn't listed:

john@ThirdEarth:~$ 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)

so how these dependencies are resolved by the dynamic loader? I found a similar issue with __gmon_start__ where, roughly speaking, is the definition of this symbol?

JohnTortugo
  • 6,356
  • 7
  • 36
  • 69

2 Answers2

4

The pthread functions in Linux are implemented in libc.

For example, on a system that I had to hand:

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

gives

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
...
Rich Drummond
  • 3,439
  • 1
  • 15
  • 16
0

To answer the second part of the question, __gmon_start__ is part of the C runtime, and is used when an executable is built for gprof(1)-style profiling.

On Ubuntu GNU/Linux, the relevant definition may be found in /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

For normal compilation runs, /usr/lib/crti.o supplies a 'weak' definition:

% nm /usr/lib/crti.o| grep -C2 gmon_start
          U _GLOBAL_OFFSET_TABLE_
          w __gmon_start__
 00000000 T _fini
 00000000 T _init
jkoshy
  • 1,793
  • 15
  • 23
  • why /usr/lib/crti.o isn't listed when I do ldd? – JohnTortugo Oct 02 '12 at 12:59
  • `/usr/lib/crti.o` is a normal relocatable, not a dynamically loadable object. You could study the output of `cc -v` to see how the object is used at link time. – jkoshy Oct 02 '12 at 16:58
  • Yes indeed. So any dependency shouldn't have been resolved at compile time? Could you please be more specific about cc -v, the output in my system aparently doesn't contain anything related to crti.o, the unique that may be related (to the question) is --enable-threads=posix. – JohnTortugo Oct 02 '12 at 17:01