Am Sun, 18 Mar 2012 21:57:57 +0100 schrieb Jacob Carlborg <d...@me.com>:
> On 2012-03-18 12:32, Johannes Pfau wrote: > > I thought about supporting emulated tls a little. The GCC emutls.c > > implementation currently can't work with the gc, as every TLS > > variable is allocated individually and therefore we don't have a > > contiguous memory region for the gc. I think these are the possible > > solutions: > > Why not use the native TLS implementation when available and roll our > own, like DMD on Mac OS X, when none exists? That's what we (mostly) do right now. We have 2 issues: * Our own, emulated TLS support is implemented in GCC. This means it's also used in C, which is great. Also GCC's emulated tls needs absolutely no special features in the runtime linker, compile time linker or language frontends. It's very portable and works with all weird combinations of dynamic libraries, dlopen, etc. But it has one quirk: It doesn't allocate TLS memory in a contiguous way, every tls variable is allocated using malloc. This means we can't pass a range to the GC for the tls variables. So we can't support this emutls in the GC. * The other issue with native TLS is that using bracketing with __tls_beg and __tls_end has corner cases where it doesn't work. We'd need an alternative to locate the TLS memory addresses and TLS sizes. But there's no standard or public API to do that. > BTW, I think it would be possible to emulate TLS in a very similar > way to how it's implemented natively for ELF. > I don't think it's that easy. For example, how would you assign module ids? For native TLS this is partially done by the compile time linker (for the main application and libraries that are always loaded), but if no native TLS is available, we can't rely on the linker to do that. We also need some way to get the current module id in running code. And how do we get the TLS initialization data? If we placed it into an array, like DMD does on OSX, we could use dlsym for dlopened libraries, but what about initially loaded libraries? Say you have application 'app', which depends on 'liba' and 'libb'. All of these have TLS data. Maybe we could implement something using dl_iterate_phdr, but that's a nonstandard extension. Compare that to GCC's emulation, which is probably slow, but 'just works' everywhere (except for the GC :-( ).
