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 <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
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?

yes

> 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
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_XX

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.

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




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.