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.