[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1437663872.3270.11.camel@inria.fr>
Date: Thu, 23 Jul 2015 17:04:32 +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, 16:42 +0200 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@...ia.fr> [2015-07-23 16:04:14 +0200]:
> > Am Donnerstag, den 23.07.2015, 15:05 +0200 schrieb Szabolcs Nagy:
> > > 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]
>
> i think it's a bit different because -lm is libc and libatomic is
> compiler runtime now. (and extern linkage behaviour for math functions
> is more clear than for "generic" atomic functions).
It is not clear if this is compiler runtime. gcc provides libatomic,
clang refers to the C library.
In any case, do you think that there would be a problem with the
approach that I propose. (provided that everybody sticks to the ABI
...)
> > > (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?
>
> i mean that on a normal build of gcc >=4.9 libatomic uses
> the gnu IFUNC feature (runtime dispatch for function symbols
> based on cpu features at early startup).
I see how that can cause problems for us.
But I don't really see how that helps. To be efficient instruction
based lock-free atomics should be inlined at compile time, no? Or do
they do lto on that kind of stuff?
> this IFUNC elf extension is not supported by musl now so
> loading a shared object with such symbols will fail
> (not sure what happens with static linking) so you have
> to build a musl specific toolchain now to use libatomic.
Static linking seems to work fine.
> (some x86_64 cpus have cmpxchg16b and there is different
> __atomic_*_16 implementation for them).
I think that it is even fair to say many if not most have them,
nowadays. The question here usually is just if people compile with
-march=native or not, which then can produce incompatible binaries.
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.
