public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/63829] Crash in__tls_init when -mcpu=arm1176jzf-s is used
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 ` aaron at aarongraham dot com
2014-11-12 1:28 ` aaron at aarongraham dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: aaron at aarongraham dot com @ 2014-11-12 1:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
--- Comment #1 from Aaron Graham <aaron at aarongraham dot com> ---
Created attachment 33945
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33945&action=edit
Disassembly of crashing result.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/63829] New: Crash in__tls_init when -mcpu=arm1176jzf-s is used
@ 2014-11-12 1:27 aaron at aarongraham dot com
2014-11-12 1:27 ` [Bug c++/63829] " aaron at aarongraham dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: aaron at aarongraham dot com @ 2014-11-12 1:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
Bug ID: 63829
Summary: Crash in__tls_init when -mcpu=arm1176jzf-s is used
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron at aarongraham dot com
ARM processor, Raspberry Pi
Offending code:
#include <memory>
thread_local std::unique_ptr<int> tls_test;
struct foo {
foo() { tls_test.reset(new int(42)); }
} const foo_instance;
int main() {}
The following works:
g++ test.cc -std=c++14
The following crashes:
g++ test.cc -std=c++14 -mcpu=arm1176jzf-s
I will attach the full disassembly for both.
Here's the basic gdb output:
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00008668 in __tls_init ()
(gdb) bt
#0 0x00008668 in __tls_init ()
#1 0x00008a14 in TLS wrapper function for tls_test ()
#2 0x000086ec in foo::foo() ()
#3 0x00008648 in __static_initialization_and_destruction_0(int, int) ()
#4 0x000086d0 in _GLOBAL__sub_I_tls_test ()
#5 0x00008a78 in __libc_csu_init ()
#6 0x4f508f18 in __libc_start_main ()
from /opt/armtools/20141030/arm-brcm-linux-gnueabi/sysroot/lib/libc.so.6
#7 0x000084fc in _start ()
(gdb) info reg
r0 0x10da0 69024
r1 0xffff 65535
r2 0xc 12
r3 0x0 0
r4 0x2 2
r5 0x10c64 68708
r6 0x2 2
r7 0x1 1
r8 0xafb35654 2947765844
r9 0xafb3565c 2947765852
r10 0x4f3a7000 1329229824
r11 0xafb354ac 2947765420
r12 0xffff0fff 4294905855
sp 0xafb354a8 0xafb354a8
lr 0x8a14 35348
pc 0x8668 0x8668 <__tls_init+16>
cpsr 0x60000010 1610612752
(gdb)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/63829] Crash in__tls_init when -mcpu=arm1176jzf-s is used
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 ` [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu aaron at aarongraham dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: aaron at aarongraham dot com @ 2014-11-12 1:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
--- Comment #2 from Aaron Graham <aaron at aarongraham dot com> ---
Created attachment 33946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33946&action=edit
Disassembly of good result.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
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
2014-12-06 16:35 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: aaron at aarongraham dot com @ 2014-12-06 1:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
2014-11-12 1:27 [Bug c++/63829] New: Crash in__tls_init when -mcpu=arm1176jzf-s is used aaron at aarongraham dot com
` (2 preceding siblings ...)
2014-12-06 1:40 ` [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu aaron at aarongraham dot com
@ 2014-12-06 16:35 ` redi at gcc dot gnu.org
2014-12-06 19:34 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2014-12-06 16:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-12-06
Ever confirmed|0 |1
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Aaron Graham from comment #3)
> I've solved this problem in my own setup by building the toolchain and
> application binaries with the same -mcpu.
Yes, that's basically what you need to do if -mcpu can affect the availability
of atomics.
This has been known for some time (the same problem exists for i386 vs i486+)
but it seems to be causing problems on ARM more and more often. I think PR
42734 is the same issue.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
2014-11-12 1:27 [Bug c++/63829] New: Crash in__tls_init when -mcpu=arm1176jzf-s is used aaron at aarongraham dot com
` (3 preceding siblings ...)
2014-12-06 16:35 ` 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
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2014-12-06 19:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Aaron Graham from comment #3)
> 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.
I think the right solution is to determine the lock policy when GCC is
configured and set it once and not have it change at compile-time based on
flags such as -mcpu.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
2014-11-12 1:27 [Bug c++/63829] New: Crash in__tls_init when -mcpu=arm1176jzf-s is used aaron at aarongraham dot com
` (4 preceding siblings ...)
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
6 siblings, 0 replies; 8+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2015-01-16 18:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
--- Comment #6 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
arm linux code should always be using the _S_atomic sequences. When the
processor doesn't have the required instructions, kernel helper routines will
be used. This ensures that code is forwards compatible to later architectures.
It's a really bad idea for the headers used in user code to be changing this
decision dynamically.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
2014-11-12 1:27 [Bug c++/63829] New: Crash in__tls_init when -mcpu=arm1176jzf-s is used aaron at aarongraham dot com
` (5 preceding siblings ...)
2015-01-16 18:55 ` rearnsha at gcc dot gnu.org
@ 2020-11-23 13:13 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-23 13:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Target Milestone|--- |9.0
Status|NEW |RESOLVED
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This was fixed in gcc-9 by the patch for PR libstdc++/67843
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-11-23 13:13 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu aaron at aarongraham dot com
2014-12-06 16:35 ` 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
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).