* Sam Varshavchik: > Florian Weimer writes: > >> * Sam Varshavchik: >> >> > libcxx.so gets built by gcc.7.3.1 with -std=c++17 -O2 >> > -fvisibility-inlines- hidden, -fno-omit-frame-pointer, and >> > -pthread. It contains some static variables that are instantiated >> > templates. It contains other static variables whose constructors >> > invoke the instantiated templates' methods that construct and >> > destruct std::unique_lock<std::mutex> of std::mutexes that are >> > static variables of the instantiated templates. Static >> > initialization of libcxx.so does not create any execution thread. >> >> What's the binding type for __pthread_key_create in libcxx.so? I >> assume that's the symbol used as a key for __gthread_active_p. > > It's whatever it inherited from <thread>. None of the translation units > directly call pthread_key_create(). They construct std::thread, std::mutex, > std::recursive_mutex, std::condition_variable, and std::lock and > std::lock_guard, for the mutexes. Sorry, I mind the binding type of the ELF symbol, in the dynamic symbol table. Is there even a relocation left? Same question for __gthread_active_p (or the function that was inlined into, if any). There are a few things that could go wrong here: The link editor resolved the weak symbol at static link time. The weak symbol is still there, but it gets processed at an inopportune time during relocation processing. Symbol interposition could be involved. STB_GNU_UNIQUE could have unanticipated side effects as well.
