Date: Sat, 25 Jul 2015 08:33:55 +0200 From: Jens Gustedt <jens.gustedt@...ia.fr> To: musl@...ts.openwall.com Subject: Re: implement stdatomic.h library interface Hello, Am Freitag, den 24.07.2015, 19:18 -0400 schrieb Rich Felker: > On Thu, Jul 23, 2015 at 02:14:15PM +0200, Joakim Sindholt wrote: > > What I don't understand is why it's seen as a necessity to re-implement > > compiler-specific functionality. Musl doesn't provide umoddi3 or other > > libgcc symbols, so why the stdatomic internals? Are you trying to > > compile without a compiler runtime library? > > I get that it could be useful to have instead of musl's current internal > > atomics but IMO only if it actually saves you the work of implementing > > the atomic primitives in the first place. > > I don't have a set-in-stone position yet on whether this should be > done, but I can give a little bit of background on the libgcc side. > Originally I had considered implementing all of the libgcc-type > compiler runtime functions in musl (and providing external definitions > for them) to eliminate the need for an additional library and possibly > allow for more-optimized implementations. However, it turned out that > there's quite a bit of diversity in the set of symbols, signatures, > calling conventions, etc. that are needed from one arch to another, > and trying to go down this path would have meant maintaining a lot > more arch-specific code that's a duplication of work already done in > the compiler's target libs. yes, I imagine, this would have been quite tedious, I definitively don't want to go for arch specific code, here > I'm not sure whether these issues apply to the atomic fallback > functions. I don't think so. The assembler that the newer versions of gcc and clang produce looks quite good. I don't have an architecture where that is really relevant at hand, but AFAICS clang seems to take the memory_order argument into account. Generally, by using these interfaces we can profit of all advances that the compiler and architecture people make for these kind of ops. > If not, then given that there seem to be serious issues > with the gcc libatomic implementation (the whole ifunc mess, compat > problems between code built with 'hard' and 'soft' atomics, etc.) it > _might_ make sense to provide them in musl. But I'd like to make sure > we consider all other options, including possibly a separate > replacement for libatomic that's independent of musl. First, the gcc libatomic is what it is, gcc. So a complete installation of musl then would always depend on the presence of gcc. And if maybe this needs a gcc (or parts of its library) that is compiled with special options, this sounds relatively prohibitive to me. clang relies on the C library (it seems on bsd) or a gcc installation as a fallback. Then the two options you mention are not exclusive. The code I have now works as standalone library and can be injected to musl to be compiled as part of it. One argument for me to want it in musl is that it is relying on locks for the lockfull versions of the calls. gcc libatomic does this with pthread_mutex_t, which is there only reasonable choice at the moment since C11 threads are not present in glibc, yet. My implementation within musl just uses LOCK/UNLOCK. This seems to be more appropriate if you have it. Lockfull atomics are not expected to work in the context of signal handlers, so a minimal lock structure with non-active wait does the trick. When compiled standalone, my code uses a simple spinlock. This makes it less efficient on high contention, but also makes it completely independent of the OS or C library. > One question about gcc's libatomic: does it work correctly with musl > if you've told gcc at build time that ifunc is not supported? I am not building gcc myself, so I can't answer that. 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.