On Fri, Aug 09, 2013 at 11:23:51AM -0500, Joel Sherrill wrote: > On 8/9/2013 11:05 AM, Deng Hengyi wrote: > > Hi Joel, > > > > I have done a test, it seems that '-march=i386' does not provide > > "__atomic_compare_exchange_n" libs. And '-march=i486' or '-march=pentium' > > can find the '__atomic_compare_exchange_n' function. > Look in the source for that methods on x86 and see what instruction > it used. If it only got added in i486, then we have to figure out > something for i386. If it was an oversight and the instruction is > on an i386, we fix the code.
The i386 architecture lacks atomic compare instructions, to the point where libstdc++ can't be built with that architecture (correct and efficient atomic operations are vital important for libstdc++, andon i386 it can't be done). The worry is that if you add "atomic" operations that don't lock for the i386 architecture, you've screwed anyone who decides to build their application for i386 hoping for maximum portability, but winds up with locks that don't lock. You could perhaps handle that for RTEMS by providing these functions in a library, but users need to understand this issue, because improper locks are tough to debug.
