[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1437660254.3270.9.camel@inria.fr>
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.
