Re: segfault on x86_64 using musl libc

[John Spencer <maillist-luajit-Am5OCHYCrcUb1SvskN2V4Q@public.gmane.org>]

On 07/16/2012 04:05 PM, Mike Pall wrote:
> Apparently musl doesn't set up thread-local storage correctly.

we had a discussion on the musl mailing list about the TLS issue,
and it turned out that I mistakenly built gcc without --disable-tls.

(musl currently doesn't support TLS for various reasons.)

with gcc fixed, luajit seems to work fine (at least for singlethreaded 
usage).

Rich came up with a clever portable (POSIX) way that could be used instead
of the existing non-threadsafe fallback code for OSX/OpenBSD/non-TLS.

please see forwarded Mail content below.


From:     Rich Felker <d...-/miJ2pyFWUyWIDz0JBNUog@public.gmane.org>
Subject:     Re: [musl] thread local storage

On Mon, Jul 16, 2012 at 02:57:22PM -0400, Gregor Richards wrote:
 > On 07/16/2012 03:02 PM, 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.
 > >
 > >is it planned to add this feature ? iirc it wasn't mentioned on
 > >the latest roadmap...
 > >
 > >
 > >
 > With a quick perusal of the LuaJIT source, this is the only instance
 > of TLS I see:
 >
 > #if LJ_UNWIND_EXT
 > #if LJ_TARGET_OSX || defined(__OpenBSD__)
 > /* Sorry, no thread safety for OSX. Complain to Apple, not me. */
 > static _Unwind_Exception static_uex;
 > #else
 > static __thread _Unwind_Exception static_uex;
 > #endif
 >
 > Convince it to use the same exception as OS X and OpenBSD and you
 > should be in business.

This is broken and non-thread-safe. Not a good idea. Instead try:

#define static_uex (*(_Unwind_Exception 
*)pthread_getspecific(static_uex_key))

where static_uex_key is a pthread_key_t initialized earlier with:
pthread_key_create(&static_uex_key, 0);

And where the thread-specific value of the key is set in thread
startup as:
_Unwind_Exception static_uex_local;
pthread_setspecific(static_uex_key, &static_uex_local);

The simplicity and generality of this solution is why __thread was
just a stupid idea to begin with...

Rich