[Bug c++/63829] New: Crash in__tls_init when -mcpu=arm1176jzf-s is used

[Bug c++/63829] New: Crash in__tls_init when -mcpu=arm1176jzf-s is used

[aaron at aarongraham dot com]

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)

[Bug c++/63829] Crash in__tls_init when -mcpu=arm1176jzf-s is used

[aaron at aarongraham dot com]

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.

[Bug c++/63829] Crash in__tls_init when -mcpu=arm1176jzf-s is used

[aaron at aarongraham dot com]

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.

[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu

[aaron at aarongraham dot com]

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.

[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu

[rearnsha at gcc dot gnu.org]

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.

[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu

[redi at gcc dot gnu.org]

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