[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120716200350.GN544@brightrain.aerifal.cx>
Date: Mon, 16 Jul 2012 16:03:51 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: thread local storage
On Mon, Jul 16, 2012 at 09:02:49PM +0200, John Spencer wrote:
> 2 out of 14 sabotage followers wanted to use a musl-based system as
> a platform for luajit (and then were never seen again).
> so i looked into adding it...
>
> luajit builds without problems on musl, but then crashes due to a
> lack of TLS.
Then the gcc was built wrong. --disable-tls should be passed when
building gcc so that attempts to use __thread generate a compile error
(to be detected in configure).
> is it planned to add this feature ? iirc it wasn't mentioned on the
> latest roadmap...
Yes, but it's one of the hardest remainind things, for a couple
reasons...
1. It involves introducing ugly arch-specific code into lots of things
that should be arch-agnostic, because the original implementors did
things this way and encoding the knowledge into gcc. This might be
possible to bypass if we drop support for the static/local TLS model
or whatever they call it and force all modules, even the main program
and static binaries, to access TLS through a function call like shared
libs have to do. Actually I'd really like to do it this way if
possible since it would allow us to change things in the future
instead of locking in ABI stuff. At the very least it probably
requires a build option to GCC and/or a special -f flag in the spec
file or GCC default specs to make this possible.
2. Dynamic linker needs to be updtaed to handle all sorts of
TLS-related relocations which I don't yet understand, so I have to
read up on them...
3. Existing implementations of TLS are just _wrong_ and crashingly so.
When a new shared lib is loaded with dlopen, it may require additional
TLS memory, and this memory must be allocated for each thread
currently running. The way glibc/NPTL works is to keep a "generation
counter" and dynamically allocate space for each thread's new TLS on
the first accerss if the ldso generation counter has increased (or
something like that). If allocation fails, there's nothing you can do
but abort the program. Naturally this is unacceptable.
Fixing it requires temporarily placing a lock on new thread creation
and allocating the new TLS space for all currently-running threads as
part of the dlopen operation, then either assigning it to them before
dlopen returns, or placing it in a reserved pool whereby they can get
it on the first access attempt. Solving this problem correctly,
without race conditions or deadlocks, etc. is rather non-trivial.
Rich
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.
