Created attachment 36966 [details] Simple seg faulting init Segfault occurs in libstdc++-v3/libsupc++/eh_ptr.cc line 190: __cxa_exception *header = globals->caughtExceptions; Attached file compiled with: g++ main.cpp -o test_static -Wall -fmessage-length=0 -std=c++1y -g3 -Wl,--whole-archive -lpthread -Wl,--no-whole-archive -static Cross compiler is: g++ -v Using built-in specs. COLLECT_GCC=/path/to/gcc_5.3_ARMv7-A/bin/g++ COLLECT_LTO_WRAPPER=/path/to/gcc_5.3_ARMv7-A/libexec/gcc/arm-linux-gnueabihf/5.3.0/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../tar/gcc-5.3.0/configure --prefix=/path/to/gcc_5.3_ARMv7-A --enable-languages=c,c++ --target=arm-linux-gnueabihf --disable-nls --with-arch=armv7-a Thread model: posix gcc version 5.3.0 (GCC) Only appears to occur in when cross compiled. native shared/static (gcc 4.9.2-10) does not occur. Having trouble testing a shared cross compiled binary due to what I imagine is libc/ld version mismatch. My distro is Mint 17.1, ARMv7-A is debian (jessie) vanilla For complete cross compiler build see: https://raw.githubusercontent.com/Dekken/scripts/master/gcc-5.3.0_x86_64_TO_ARMv7-A.sh
Also occurs with a 4.9.2 cross compiler. g++ -v Using built-in specs. COLLECT_GCC=./g++ COLLECT_LTO_WRAPPER=/path/to/gcc_4.9_ARMv7-A/libexec/gcc/arm-linux-gnueabihf/4.9.2/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../tar/gcc-4.9.2/configure --prefix=/path/to/gcc_4.9_ARMv7-A --enable-languages=c,c++ --target=arm-linux-gnueabihf --disable-nls --with-arch=armv7-a Thread model: posix gcc version 4.9.2 (GCC)
Also happens on trunk. I'm taking a look at this
Anything I can do to help?
I managed to look into this in more detail with a colleague. The segfault happens because the implementation of __tls_get_addr in glibc returns an invalid pointer. This seems to be a problem with static linking only, and dynamic linking will avoid the problem. A slightly simplified test case (without the exception handling) is: #include <cstdio> #include <thread> __thread int __attribute__ ((tls_model ("global-dynamic"))) x = 10; class Thread { public: void operator()(){ fprintf(stderr, "testing (%i) ...\n", x); } }; int main(void){ Thread t; std::thread th(std::ref(t)); th.join(); return 0; } If you install a copy of jessie filesystem somewhere on your build machine, you should be able to compile and link against the libraries on that version using --sysroot=/path/to/fs. This should allow you to create dynamically linked binaries which work on your target I've created a glibc bug for this https://sourceware.org/bugzilla/show_bug.cgi?id=19826. Since I don't think this is a bug in gcc, I'll close this bug.