[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <66dbe85b.dNq.dMV.23.hGZuqs@mailjet.com>
Date: Thu, 23 Jul 2015 18:32:26 +0200
From: Joakim Sindholt <opensource@...sha.com>
To: musl@...ts.openwall.com
Subject: Re: implement stdatomic.h library interface
On Thu, 2015-07-23 at 17:04 +0200, Jens Gustedt wrote:
> 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.
compiler-rt provides the fallback symbols:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/atomic.c
> 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?
The symbols are only used as a fallback, just like with large division
and the like. At least with clang the instructions are directly
inserted. The reason they use ifuncs is to optimize the slow path (dumb
as it sounds).
> > 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.
Then you're not hitting the fallback symbols. They will initially be
NULL and you should get SIGSEGV. At least this was the result I saw when
trying to use ifunc resolver in a static binary with musl.
I still don't know why I get caught in the spam filter. This email will
be as delayed as the one I sent hours ago as it needs manual approval. I
apologize if this is antiquated by the time it reaches the list.
-- Joakim
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.
