[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1437806035.23129.2.camel@inria.fr>
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.
