Is pthread in glibc.so implemented by a weak character to provide pthread stub functions?

Question

is pthread in glibc.so implemented with a weak character to provide pthread functions?

I know that there is pthread.so to provide functions similar to pthread in glibc.so , someone said that pthread in glibc only provides a stub and will be replaced when explicitly bound to lpthread .

So my question is how to maintain it? using a weak character or other technique?

is libssl similar to pthread in glibc ?

Answer 1

Yes, glibc uses a stub implementation of various pthread functions, so single-threaded programs don’t need to spend cycles doing things like locking and unlocking mutexes, and yet they don’t need to reference another C library (for example, for example, in the Microsoft world).

For example, according to POSIX, every time you call fputc(ch, stream) , the mutex is locked and unlocked. If you do not want this, you call fputc_unlocked . But when you do this, you use the POSIX extension associated with stream processing; This is not a suitable solution for programs that do not use POSIX or do not use the streaming API.

Overriding stub pthread functions with real ones (in dynamic glibc) is not based on weak characters . The shared library mechanism allows you to override undefined definitions.

Weak characters are a mechanism that allows you to redefine a character with static binding.

If you need a source for the above statement, here it is:

"Note that a definition in a DSO that is weak has no effect. Weak definitions play a role in static communication." [Ulrich Drapper, "How to write shared libraries . "

If you run nm in static glibc on your system (if you have one), libc.a , you will notice that functions like pthread_mutex_lock are marked as weak. In the dynamic version of libc.so.<whatetever> functions are not marked as weak.

Note: you must use nm -D or nm --dynamic to view characters in a shared library. nm will not give anything in the shared library. If so, you are looking at debugging symbols, not dynamic symbols.

Answer 2

See this SO answer . You can use several methods to determine the same symbol in several libraries with which the program is associated, depending on whether dynamic or static linking is used.

• Symbolic Intervention When dynamic linking, if a symbol is defined in several libraries, then the linker will use the first version it finds (unless the symbols are internal, hidden or protected, see this blog article for a description of this)

• Weak objects. When static linking, if the linker finds two characters with the same name and one is a “weak” link, then the linker will use an asymmetric link.

• Character version compatibility can also play a role.

In almost all cases, programs are dynamically linked to libc.

You can see the order of loading libs with ldd:

 $ ldd simple_pthread linux-vdso.so.1 => (0x00007fffaddff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa13a474000) libc.so.6 => /lib64/libc.so.6 (0x00007fa13a0e0000) /lib64/ld-linux-x86-64.so.2 (0x00007fa13a6a0000) 

Here you can see that libpthread before libc is in binding order. It almost always happens; libc is always bound last, using the default compiler options.

Thus, the libpthread-related program will use the pthread versions of these characters, since they occur first in binding order.

If you are still not sure, running your program with the environment variable LD_DEBUG set to "bindings" will show the actual character bindings that occur.

If you use static binding, you will refer to libc.a instead of libc.so. You can use "nm" to display the details of the character. Weak characters have a "W" or "w" for their type.

(@Kaz credit for pointing out that weak characters do not affect dynamic binding).