public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "aaron at aarongraham dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu Date: Sat, 06 Dec 2014 01:40:00 -0000 [thread overview] Message-ID: <bug-63829-4-s4LQALnMh6@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-63829-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2014-12-06 1:40 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-11-12 1:27 [Bug c++/63829] New: Crash in__tls_init when -mcpu=arm1176jzf-s is used aaron at aarongraham dot com 2014-11-12 1:27 ` [Bug c++/63829] " aaron at aarongraham dot com 2014-11-12 1:28 ` aaron at aarongraham dot com 2014-12-06 1:40 ` aaron at aarongraham dot com [this message] 2014-12-06 16:35 ` [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu redi at gcc dot gnu.org 2014-12-06 19:34 ` redi at gcc dot gnu.org 2015-01-16 18:55 ` rearnsha at gcc dot gnu.org 2020-11-23 13:13 ` redi at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-63829-4-s4LQALnMh6@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).