Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Jul 2015 16:04:14 +0200
From: Jens Gustedt <>
Subject: Re: implement stdatomic.h library interface

Am Donnerstag, den 23.07.2015, 15:05 +0200 schrieb Szabolcs Nagy:
> so you plan to implement gcc libatomic abi in musl?


> it seems gcc does not pass -latomic automatically to the linker
> which is ugly (i think atomics should work transparently), but
> ppl using atomics will.

I think the situation is somewhat comparable to -lm. Other libraries
may implement that as separate .a or .so, we should just integrate it
to the whole, and provide an empty libatomic.[a|so]

So with whatever arguments people call their linker, it should work
for us.

> (there is another problem that gcc libatomic on x86 uses ifunc
> dispatch for some __atomic_*_16 functions which does not work
> with musl now, this can be worked around by rebuilding gcc with
> --disable-gnu-indirect-function.)

Can you explain in more detail what is not working?

The libatomic abi consists in providing stubs for all
__atomic_*_[1|2|4|8|16] functions, for the case that these can't use
processor atomics.

I plan to provide all these, by pointing to the lock-full "memory"
variants if there is not processor CAS for the type. These "memory"
variants are also the fallback for all other sizes. Works sufficiently
well already, I think.

The memory version is important for atomics on structs that are used
for lock-free dynamic data types. Typically they would need some
atomic for a pair of pointers or so, to avoid the ABA problem. On some
archs such a pair would fit into a lock-free atomic, on others it'd
have to be done by a lockfull replacement.

My strategy is to provide versions according to the presence or not of

But you are right, the "16" case, that is 16byte atomics need some
careful inspection. The documentation says something that they provide
the primitives if __int128_t exists. (Or suppose that the stub
functions then are implemented?)

What also bugs me a bit, is that I'd like to prevent objects that are
compiled with different architecture version together. If one uses a
processor atomic for 16 byte and the other goes into the "memory"
variant, they wouldn't even detect it.


:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: ::

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.