[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150723144238.GD382@port70.net>
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.
