atomic builtin

That's a call to libatomic. libatomic is unsupported for baremetal toolchains.

Could you use https://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html for your atomic operations?

Hi Jonathan,

What CPU are you targeting? If it's a Cortex-M that's expected because they do not have instructions for 64bit atomic operations. uint32_t would work on these devices and uint64_t would work on Cortex-A and Cortex-R devices.

Best regards.

Hi,

I use cortex-M4 devices. I know that uint64_t was unsupported. Thats why the atomic rely on atomic_store_8 to do something atomic. I have found a base libatomic on gcc wiki that help me to write the stub. I know this is very os dependant and need to be adjusted for each situation.

http://gcc.gnu.org/wiki/Atomic/GCCMM?action=AttachFile&do=view&target=libatomic.c

At least I have been able to use it on M4.

I don't know if they exist other implementation of this library for M4 devices ? Something to base on developement.

Regards

Jonathan

I had a little look at that library, and I think it contains a critical flaw that makes it fail here. The implementation uses spinlocks to control access to atomics bigger than 32 bit. The idea is simple - get the lock, do the access, release the lock. And spinlocks are an efficient but risky way to do this on a system like Linux, but a terrible way for the typical embedded system. The problem is if one thread holds the long, and another higher priority thread gets the processor access and tries to get the lock - that higher priority thread will wait indefinitely for the lock. There is no scope for priority boosts.

A quick test of a couple of atomic accesses in gcc 6 for the ARM show very poor implementations - library calls for things that should be a couple of assembly instructions.