https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
Aaron Graham <aaron at aarongraham dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|c++ |libstdc++
Summary|Crash in__tls_init when |_Lock_policy used in
|-mcpu=arm1176jzf-s is used |thread.cc can cause
| |incompatibilities with
| |binaries using different
| |-mcpu
--- Comment #3 from Aaron Graham <aaron at aarongraham dot com> ---
This is a C++ standard library problem.
If the toolchain is compiled for generic arm processors, the C++ standard
library uses the "_S_mutex" _Lock_policy (see ext/concurrence.h).
// Compile time constant that indicates prefered locking policy in
// the current configuration.
static const _Lock_policy __default_lock_policy =
#ifdef __GTHREADS
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
&& defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
_S_atomic;
#else
_S_mutex;
#endif
#else
_S_single;
#endif
If the compiler is then used to build binaries using -mcpu=arm1176jzf-s (or
cortex-a9 or just about anything else) then those binaries use the "_S_atomic"
_Lock_policy and are *incompatible* with the standard library built with the
compiler.
Here's some simpler code that was failing because of this problem:
void foo() {}
int main() { std::thread(&foo).join(); }
This fails because execute_native_thread_routine accesses a shared_ptr, thereby
requiring all binaries that link to it to use its locking policy, or else.
I've solved this problem in my own setup by building the toolchain and
application binaries with the same -mcpu.
A more general solution might be to move more code out of places like thread.cc
and into the headers.
