Date: Thu, 23 Jul 2015 16:42:39 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: implement stdatomic.h library interface * 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). > > (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). 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. (some x86_64 cpus have cmpxchg16b and there is different __atomic_*_16 implementation for them).
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.