Am Donnerstag, den 23.07.2015, 18:32 +0200 schrieb Joakim Sindholt:
> > 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).

sure, so my understanding is, that these IFUNC symbols are used as
fallbacks. The IFUNC mechanism is then used to put arch specific code
in place as such a replacement.

> > > 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 probably explained wrong what I was doing. Sure if we would use the
existing libatomic, we would hit that wall. Thus the need to implement
these calls in musl directly, such that they don't use or need IFUNC.

What I was refering to as "working" is such a different approach:

at musl compile time, decide which atomics are supported on
instruction level (or not). This can be done by testing for
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_XX

For those where it is supported, compile the stubs by using the
builtins. These stubs will probably never be used, but they are there
if a user compiles with an oldish compiler, conservative arch
options or switches off the builtins.

Those where it is not supported are implemented with the generic
lockfull memcpy-memcmp version. On my platform this is usually the 16
byte version, or not depending on the arch options.

This is a bit less optimal than the IFUNC version, because it fixes
the instruction set that can be used at musl-compile time.

> 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.

No problem for me.

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 ::