On 11/17/20 4:41 PM, Richard Earnshaw (lists) wrote: > > libgcc is *still* the wrong place for this. It belongs in the system > library (eg newlib, or glibc, or whatever), which knows about the system > it's running on. (Sorry, I should have said this before, but I've > context-switched this out since it's been a long time since it came up). >
No problem. I just saw it from the other end. It is odd that this problem does not go away even if gcc is configured with --disable-threads, which should be the default for arm-none-eabi anyway. If we assume a threaded environment then it is still libgcc which does not define __GTHREADS in libgcc/gthr.h, and libstdc++'s __cxa_guard_acquire is not making use of functions like __gthread_mutex_lock. But that appears to be this way by design. Of course the race is not fixed if you ask newlib to implement just this __sync_synchronize function. > This hack will just lead to silent code failure of the worst kind > (non-reproducable, racy) at runtime. > So in a arm-none-eabi system with armv6 or higher where the intrinsic __sync_synchronize is not a library call but an instruction we have exactly this worst kind scenario, already. It is however possible that the default of -fthreadsafe_statics is inappropriate for --disable-threads ? Bernd. > R. >
